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Abstract 

This paper presents a computational model for the cooperation of constraint domains 
and an implementation for a particular case of practical importance. The computational 
model supports declarative programming with lazy and possibly higher-order functions, 
predicates, and the cooperation of different constraint domains equipped with their res- 
pective solvers, relying on a so-called Constraint Functional Logic Programming {CFLP) 
scheme. The implementation has been developed on top of the CFLP system TOy, 
supporting the cooperation of the three domains TL, 1Z and TT>, which supply equality and 
disequality constraints over symbolic terms, arithmetic constraints over the real numbers, 
and finite domain constraints over the integers, respectively. The computational model 
has been proved sound and complete w.r.t. the declarative semantics provided by the 
CFLP scheme, while the implemented system has been tested with a set of benchmarks 
and shown to behave quite efficiently in comparison to the closest related approach we are 
aware of. 
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1 Introduction 

Constraint Programming relies on constraint solving as a powerful mechanism for 
tackling practical applications. The well-known CLP Scheme f Jaff ar and Lassez 1987 
Uaffar and Maher~1 994; Jaffar et al. 1998) provides a powerful and practical frame- 
work for constraint programming which inherits the clean semantics and declarative 
style of logic programming. Moreover, the combination of CLP with functional pro- 
gramming has given rise to various so-called CFLP (Constraint Functional Logic 
Programming) schemes, developed since 1991 and aiming at a very expressive com- 
bination of the constraint, logical and functional programming paradigms. 

This paper tackles foundational and practical issues concerning the efficient use 
of constraints in CFLP languages and systems. Both the CLP and the CFLP 
schemes must be instantiated by a parametrically given constraint domain T> which 
provides specific data values, constraints based on specific primitive operations, 
and a dedicated constraint solver. Therefore, there are different instances CLP{T>) 
of the CLP scheme for various choices of T>, and analogously for CFLP, whose 
instances CFLP(V) provide a declarative framework for any chosen domain V. 
Useful 'pure' constraint domains include the Herbrand domain Ti, which supplies 
equality and disequality constraints over symbolic terms; the domain 1Z which sup- 
plies arithmetic constraints over real numbers; and the domain TT> which supplies 
arithmetic and finite domain constraints over integers. Practical applications, how- 
ever, often involve more than one 'pure' domain, and sometimes problem solutions 
have to be artificially adapted to fit a particular choice of domain and solver. 

Combining decision procedures for theories is a well-known problem, thoroughly 
investigated since the seminal paper of Nelson and Oppen (Nels on~and Oppen 1979[ ). 
In constraint programming, however, the emphasis is placed in computing an- 
swers by the interaction of constraint solvers with user given programs, rather 
than in deciding satisfiability of formulas. The cooperative combination of con- 
straint domains and solvers has evolved during the last decade as a relevant re- 
search issue that is raising an increasing interest in the CLP community. Here we 
mention (jBaader and Schulz 19951 IBenhamou 19961 |Monfroy 1996| |Monfroy 1998 



IGranvilliers et al. 2 001; Mar in et al. 2001|[Hofstedt 20011|Monfroy and Castro 2004 



|Hofstedt and Pepper 2007 ) as a limited selection of references illustrating various 



approaches to the problem. An important idea emerging from the research in this 
area is that of 'hybrid' constraint domain, built as a combination of simpler 'pure' 
domains and designed to support the cooperation of its components, so that more 
declarative and efficient solutions for practical problems can be promoted. 



1.1 Aims of this paper 

The first aim of this paper is to present a computational model for the coopera- 
tion of constraint domains in the CFLP context, where sophisticated functional 
programming features such as higher-order functions and lazy evaluation must col- 
laborate with constraint solving. Our computational model is based on the CFLP 
scheme and goal solving calculus recently proposed in ( |L6pez-Fraguas et al. 20041 
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|L6pez-Fraguas et al. 2007 ), which will be enriched with new mechanisms for mod- 
eling the intended cooperation. Moreover, we rely on the domain cooperation tech- 
niques proposed in our previous papers IjEstevez-Martm et al. 20071 lEstevez-Martm et al. 2007( 
Estcvez-Martm et al. 2008), where we have introduced so-called bridges as a key 
tool for communicating constraints between different domains. 

Bridges are constraints of the form X #==d j)t LY which relate the values of two 
variables X :: dj, Y :: d 3 of different base types, requiring them to be equivalent. 
For instance, X #==mt,reai Y (abbreviated as X #== Y in the rest of the paper) 
constrains the real variable Y : : real to take an integral real value equivalent to 
that of the integer variable X : : int. Note that the two types int and real are 
kept distinct and their respective values are not confused. 

Our cooperative computation model keeps different stores for constraints corres- 
ponding to various domains and solvers. In addition, there is a special store where 
the bridge constraints which arise during the computation are placed. A bridge 
constraint X #== Y available in the bridge store can be used to project constraints 
involving the variable X into constraints involving the variable Y, or vice versa. For 
instance, the 1Z constraint RX <= 3.4 (based on the inequality primitive <= - 'less 
or equal' - for the type real) can be projected into the TV constraint X #<= 3 
(based on the inequality primitive #<= - 'less or equal' - for the type int) in case 
that the bridge X #== RX is available. Projected constraints are submitted to their 
corresponding store, with the aim of improving the performance of the correspond- 
ing solver. In this way, projections behave as an important cooperation mechanism, 
enabling certain solvers to profit from (the projected forms) of constraints originally 
intended for other solvers. 

We have borrowed the idea of constraint projection from the work of P. Hofstedt 
et al. Pofstedt 2000aUHofstedt 2000bl IHoIstedt 20011 [Hofstedt and Pepper 2007| , 
adapting it to our CFLP scheme and adding bridge constraints as a novel technique 
which makes projections more flexible and compatible with type discipline. In order 
to formalize our computation model, we present a construction of coordination do- 
mains C as a special kind of 'hybrid' domains built as a combination of various 'pure' 
domains intended to cooperate. In addition to the specific constraints supplied by 
its various components, coordination constraints also supply bridge constraints. As 
particular case of practical interest, we present a coordination domain C tailored to 
the cooperation of the three pure domains H, 1Z and TT>. 

Building upon the notion of coordination domain, we also present a formal goal 
solving calculus called CCLNC(C) (standing for Cooperative Constraint Lazy Nar- 
rowing Calculus over C) which is sound and complete with respect to the instance 
CFLP{C) of the generic CFLP scheme. CCLNC(C) embodies computation rules 
for creating bridges, invoking constraint solvers, and performing constraint projec- 
tions as well as other more ad hoc operations for communication among different 
constraint stores. Moreover, CCLNC(C) uses lazy narrowing (a combination of lazy 
evaluation and unification) for processing calls to program defined functions, en- 
suring that function calls are evaluated only as far as demanded by the resolution 
of the constraints involved in the current goal. 

A second objective of the paper is to describe the implementation of a CFLP 
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system which supports the cooperation of solvers via bridges and projections for the 
Herbrand domain H and the two numeric domains 1Z and J-"D, following the compu- 
tational model provided by the CCLNC(C) goal solving calculus. The implementa- 
tion follows the techniques summarized in our previous papers (Estcvez-Martm c t al. 20071 
lEstevez- Martin et al. 2008")) . It has been developed on top of the TOy system 
([Arenas et al. 2007| , which is in turn implemented on top of SICStus Prolog ( SICStus Prolog 2007 ) 
The TOy system already supported non-cooperative CFLP programming using 
the TT> and TZ solvers provided by SICStus along with Prolog code for the 7i 
solver. This former system has been extended, including a store for bridges and 
implementing mechanisms for computing bridges and projections according to the 
CCLNC(C) computation model. 

Last but not least, another important aim of the paper is to provide some evi- 
dence on the practical use and performance of our implementation. To this purpose, 
we present some illustrative examples and a set of benchmarks tailored to test the 
performance of CCLNC(C) as implemented in TOy in comparison with the clos- 
est related system we are aware of, namely the META-S tool (Frank ct al. 2003a; 
IFrank et~a l. 2003b; IFrank et al. 2005]) which implements Hofstedt's framework for 
solver cooperation (Hofstcd t and Pep per 2007). The experimental results we have 
obtained are quite encouraging. 

The present paper thoroughly revises, expands and elaborates our previous re- 
lated publications in many respects. In fact, (lEstcvcz-Mart nTet al. 2007)) was a 
very preliminary work which focused on presenting bridges and providing evidence 
for their usefulness. Building upon these ideas, (Estcvcz-Martm ct al. 2007) intro- 
duced coordination domains and a cooperative goal solving calculus over an arbi- 
trary coordination domain, proving local soundness and completeness results, while 
(|Estev cz-Mart in~et al. 2008)) further elaborated the cooperative goal solving calcu- 
lus, providing stronger soundness and completeness results and experimental data 
on an implementation tailored to the cooperation of the domains TL, TT> and 1Z. Sig- 
nificant novelties in this article include: technical improvements in the formalization 
of domains; a new notion of solver taking care of critical variables and well- typed 
solutions; a new notion of domain-specific constraint to clarify the behaviour of 
coordination domains; various elaborations in the cooperative goal solving trans- 
formations needed to deal with critical variables and domain-specific constraints; 
a more detailed presentation of the implementation results previously reported in 
(jEstevez-Martm et al. "20071 lEstevez- Martin et al. 20081 lEstevez-Martm et al. 20"08)) ; 
and quite extensive comparisons to other related approaches. 



1.2 Motivating Examples 

As a motivation for the rest of the paper, we present in this subsection a few sim- 
ple examples, intended to illustrate the different cooperation mechanisms that are 
supported by the computation model CCLNC(C), as well as the benefits resulting 
from the cooperation. 

To start with, we present a small program written in TOy syntax, which solves 
the problem of searching for a 2D point lying in the intersection of a discrete 
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grid and a continuous region. The program includes type declarations, equations 
for defining functions and clauses for defining predicates. Type declarations are 
similar to those used in functional languages such as Haskell ( jPeyton- Jones 2002). 
Function applications use curried notation, also typical of Haskell and other higher- 
order functional languages. The equations used to define functions must be under- 
stood as conditional rewrite rules of the form ft n — * r <^ A, whose condition 
A is a conjunction of constraints. Predicates are viewed as Boolean functions, and 
clauses are understood as an abbreviation of conditional rewrite rules of the form 
ft n — * true 4= A, whose righthand side is the Boolean constant true. Moreover, 
conditions consisting of a Boolean expression exp are understood as an abbreviation 
of the strict equality constraint exp == true, using the strict equality operator == 
which is a primitive operation supplied by the Herbrand domain TL. The program's 
text is as follows: 

°/ Discrete versus continuous points: 
type dPoint = (int, int) 
type cPoint = (real, real) 



7» Sets and membership: 
type setOf A = A -> bool 
isln : : setOf A -> A -> bool 
isln Set Element = Set Element 

7» Grids and regions as sets of points: 
type grid = setOf dPoint 
type region = setOf cPoint 



'/, Predicate for computing intersections of regions and grids: 
bothln : : region -> grid -> dPoint -> bool 
bothln Region Grid (X, Y) :- X #== RX, Y #== RY, 

isln Region (RX, RY) , isln Grid (X,Y), labeling [ ] [X,Y] 

7. Square grid (discrete) : 

square : : int -> grid 

square N (X,Y) :- domain [X,Y] ON 

% Triangular region (continuous) : 
triangle : : cPoint -> real -> real -> region 
triangle (RXO.RYO) B H (RX,RY) :- 
RY >= RYO - H, 

B*RY-2*H*RX<=B* RYO - 2 * H * RXO, 
B*RY+2*H*RX<=B* RYO + 2 * H * RXO 



7. Diagonal segment (discrete) 
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diagonal : : int -> grid 

diagonal N (X,Y) :- domain [X,Y] ON, X == Y 

7» Parabolic line (continuous) : 
parabola : : cPoint -> region 

parabola (RXO.RYO) (RX.RY) : - RY - RYO == (RX - RXO) * (RX - RXO) 

Because of all the conventions explained above, the clause for the bothln predicate 
included in the program must be understood as an abbreviation of the rewrite rule 

bothln Region Grid (X,Y) -> true <== 
X #== RX, Y #== RY, 

isln Region (RX,RY) == true, isln Grid (X,Y) == true, 
labeling [ ] [X,Y] 

whose condition includes two bridge constraints, two strict equality constraints pro- 
vided by the domain TL, and a last constraint using the labeling primitive supplied 
by the domain TV. The other clauses and equations in the program can be analo- 
gously understood as conditional rewrite rules whose conditions are constraints 
supported by some of the three domains H, 1Z or TV. 

Let us now discuss the intended meaning of the program. The bothln predicate 
is intended to check if a given discrete point (X,Y) belongs to the intersection of 
the continuous region Region and the discrete grid Grid given as parameters, and 
the constraints occurring as conditions are designed to this purpose. More pre- 
cisely, the two bridge constraints X #== RX, Y #== RY ensure that the discrete 
point (X,Y) and the continuous point (RX,RY) are equivalent; the two strict equal- 
ity constraints isln Region (RX, RY) == true, isln Grid (X,Y) == true en- 
sure membership to Region and Grid, respectively; and finally the TV constraint 
labeling [ ] [X , Y] ensures that the variables X and Y are bound to integer values. 




E 



Fig. 1. Triangular region 

Note that both grids and regions are represented as sets, represented them- 
selves as Boolean functions. They can be passed as parameters because our pro- 
gramming framework supports higher-order programming features. The program 
also defines two functions square and triangle, intended to compute representa- 
tions of square grids and triangular regions, respectively. Let us discuss them in 
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turn. We first note that the type declaration for triangle can be written in the 
equivalent form triangle :: cPoint -> real -> real -> (cPoint -> bool). 
A function call of the form triangle (RX0,RY0) B H is intended to return a 
Boolean function representing the region of all continuous 2D points lying within 
the isosceles triangle with upper vertex (RXO.RYO), base B and height H. Apply- 
ing this Boolean function to the argument (RX,RY) yields a function call writ- 
ten as triangle (RXO.RYO) B H (RX.RY) and expected to return true in case 
that (RX,RY) lies within the intended isosceles triangle, whose three vertices are 
(RXO.RYO), (RX0-B/2,RY0-H) and (RXO+B/2 , RYO-H) . The three sides of the trian- 
gle are mathematically characterized by the equations RY = RYO-H, B*RY-2*H*RX 
= B*RY0-2*H*RX0 and B*RY+2*H*RX = B*RY0+2*H*RX0 (corresponding to the lines 
n, t-i and r3 in Fig.[TJ respectively). Therefore, the conjunction of three linear in- 
equality 1Z constraints occurring as conditions in the clause for triangle succeeds 
for those points (RX,RY) lying within the intended triangle. 

Similarly, the type declaration for square can be written in the equivalent form 
square :: int -> (dPoint -> bool) , and a function call of the form square N is 
intended to return a Boolean function representing the grid of all discrete 2D points 
with coordinates belonging to the interval of integers between and N. Therefore, 
a function call of the form square N (X,Y) must return true in case that (X,Y) 
lies within the intended grid, and for this reason the single TT> constraint placed 
as condition in the clause for square has been chosen to impose the interval of 
integers between and N as the domain of possible values for the variables X and Y. 

Finally, the last two functions diagonal and parabola are defined in such a way 
that diagonal N returns a Boolean function representing the diagonal of the grid 
represented by square N, while parabola (RX0,RY0) returns a Boolean function 
representing the parabola whose equation is RY-RYO = (RX-RXO) * (RX-RXO) . The 
type declarations and clauses for these functions can be understood similarly to the 
case of square and triangle. 

Different goals can be posed and solved using the small program just described 
and the cooperative goal solving calculus CCLNC{C) as implemented in the TOy 
system. For the sake of discussing some of them, assume two fixed positive integer 
values d and n such that n = 2*d. Then (d,d) is the middle point of the grid 
(square n), which includes (n+1) 2 discrete points. The three following goals ask 
for points in the intersection of this fixed square grid with three different triangular 
regions: 

• Goal 1: bothln (triangle (d, d+0.75) n 0.5) (square n) (X,Y). 

This goal fails. 

• Goal 2: bothln (triangle (d, d+0.5) 2 1) (square n) (X,Y). 

This goal computes one solution for (X,Y) , corresponding to the point (d,d) . 

• Goal 3: bothln (triangle (d, d+0.5) (2*n) 1) (square n) (X,Y). 
This goal computes n+1 solutions for (X,Y), corresponding to the points 
(0,d), (l,d), (n,d). 

These three goals are illustrated in Fig. [2] for the particular case n = 4 and d 
= 2, although the shapes and positions of the three triangles with respect to the 
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middle point of the grid would be the same for any even positive integer n = 2*d. 
The expected solutions for each of the three goals are clear from the figures. 




Fig. 2. Intersection of a fixed square grid with three different triangular regions 

In the three cases, cooperation between the 1Z solver and the TV solver is crucial 
for the efficiency of the computation. In the case of Goal 2, cooperative goal solving 
implemented in TOy according to the CCLNC(C) computation model uses the 
clauses in the program and eventually reduces the problem of solving the goal to 
the problem of solving a constraint system that, suitably simplified, becomes: 

X #== RX, Y #== RY, 

RY >= d-0.5, RY-RX <= 0.5, RY+RX <= n+0.5, 
domain [X,Y] n, labeling [] [X,Y] . 

The TOy system has the option to enable or disable the computation of projections. 
When projections are disabled, the two bridges do still work as constraints, and 
the last TV constraint labeling [] [X,Y] forces the enumeration of all possible 
values for X and Y within their domains, eventually finding the unique solution X 
= Y = d after C(n 2 ) steps. When projections are enabled, the available bridges are 
used to project the TZ constraints RY >= d-0 . 5 , RY-RX <= 0.5, RY+RX <= n+0 . 5 
into the TV constraints Y #>= d, Y#-X #<= 0, Y#+X #<= n. Since n = 2*d, the 
only possible solution of these inequalities is X = Y = d. Therefore, the TV solver 
drastically prunes the domains of X and Y to the singleton set {d}, and solving the 
last labeling constraint leads to the unique solution with no effort. For a big value 
of n = 2*d the performance of the computation is greatly enhanced in comparison 
to the case where projections are disabled, as confirmed by the experimental results 
given in Subsection 15.21 The expected speed-up in execution time corresponds to 
the improvement from the 0(n 2 ) steps needed to execute the labeling constraint 
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labeling [] [X,Y] when the domains of both X and Y have size 0(n), to the 
0(1) steps needed to execute the same constraint when the domains of both X and 
Y have been pruned to size 0{\). Similar speedups are observed when solving Goal 
1 (which finitely fails, and where the expected execution time also improves from 
C(n 2 ) to 0(1)) and Goal 3 (which has just n+1 solutions, and where the expected 
execution time reduces from C(n 2 ) to O(io.)). 

The three goals just discussed mainly illustrate the benefits obtained by the TV 
solver from the projection of TZ constraints. In fact, when TOy solves these three 
goals according to the cooperative computation model CCLNC(C), the available 
bridge constraints also allow to project the TV constraint domain [X,Y] On 
into the conjunction of the TZ constraints <= RX, RX <= n, <= RY, RY <= n. 
These constraints, however, are not helpful for optimizing the resolution of the pre- 
viously computed TZ constraints RY >= d-0.5, RY-RX <= 0.5, RY+RX <= n+0.5. 

In general, it seems easier for the TV solver to profit from the projection of 1Z 
constraints than the other way round. This is because the solution of many practical 
problems is arranged to finish with solving TV labeling constraints, which means 
enumerating values for integer variables, and this process can greatly benefit from 
a reduction of the variables' domains due to previous projections of 1Z constraints. 
However, the projection of TV constraints into 1Z constraints can help to define the 
intended solutions even if the performance of the TZ solver does not improve. For 
instance, assume that the value chosen for n = 2*d is big, and consider the goal 

• Goal 4: bothln (triangle (d,d) n d) (square 4) (X,Y). 

whose resolution eventually reduces to the problem of solving a constraint system 
that, suitably simplified, becomes: 

X #== RX, Y #== RY, 

RY >= 0, RY-RX <= 0, RY+RX <= n, 

domain [X,Y] 4, labeling [] [X,Y] . 

The solutions correspond to the points lying in the intersection of a big isosceles 
triangle and a tiny square grid. Projecting RY >= 0, RY-RX <= 0, RY+RX <= n 
into TV constraints via the two bridges X #== RX , Y #== RY brings no significant 
gains to the TZ solver whose task is anyhow trivial. The TZ constraints projected 
from domain [X,Y] 4 (i.e., <= RX, RX <= 4, <= RY, RY <= 4) do not im- 
prove the performance of the TZ solver either, but they help to define the intended 
solutions. In this example, the last labeling constraint eventually enumerates the 
right solutions even if the projection of the domain constraint to TZ does not take 
place, but this projection would allow the TZ solver to compute suitable constraints 
as solutions in case that the labeling constraint were removed. 

There are also some cases where the performance of the TZ solver can benefit from 
the cooperation with the TV domain. Consider for instance the goal 

• Goal 5: bothln (parabola (2,0)) (diagonal 4) (X,Y). 

asking for points in the intersection of the discrete diagonal segment of size 4 and 
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a parabola with vertix (2,0) (see Fig. [3]). Solving this goal eventually reduces to 
solving a constraint system that, suitably simplified, becomes: 

X #== RX, Y #== RY, 
RY == (RX-2)*(RX-2) , 

domain [X,Y] 4, X == Y, labeling [] [X,Y] . 




Fig. 3. Intersection of a parabolic line and a diagonal segment 

Cooperative goal solving as implemented in TOy processes the constraints within 
the current goal in left-to right order, performing projections whenever possible, and 
sometimes delaying a constraint that cannot be managed by the available solvers. 
In this case, the quadratic TZ constraint RY == (RX-2) * (RX-2) is delayed because 
the TZ solver used by TOy (inherited form SICStus Prolog) cannot solve non-linear 
constraints. However, since this strict equality relates expressions of type real, it 
is accepted as a TZ constraint and projected via the available bridges, producing 
the TV constraint Y == (X-2) * (X-2) , which is submitted to the TV solver. Next, 
projecting the TV constraint domain [X,Y] 4 and solving X == Y causes the 
TZ constraints <= RX, RX <= 4, <= RY, RY <= 4 to be submitted to the TZ 
solver, and the variable X to be substituted in place of Y all over the goal. The 
bridges X #== RX, Y #== RY become then X #== RX, X #== RY, and the label- 
ing constraint becomes labeling [] [X,X]. An especial mechanism called bridge 
unification infers from the two bridges X #== RX , X #== RY the strict equality 
constraint RX == RY, which is solved by substituting RX for RY all over the cur- 
rent goal. At this point, the delayed TZ constraint becomes RX == (RX-2) * (RX-2) . 
Finally, the TV constraint labeling [] [X,X] is solved by enumerating all the 
possible values for X allowed by its domain, and continuing a different alternative 
computation with each of them. Due to the bridge X #== RX, each integer value 
v assigned to X by the labeling process causes the variable RX to be bound to the 
integral real number rv equivalent to v (in our computation model, this is part of 
the behaviour of a solver in charge of solving bridge constraints). The binding of RX 
to rv awakens the delayed constraint RX == (RX-2) * (RX-2) , which becomes the 
linear (and even ground) constraint rv == (rv-2) * (rv-2) and succeeds if rv is an 
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integral solution of the delayed quadratic equation. In this way, the two solutions 
of Goal 5 are eventually computed, corresponding to the two points (X,Y) lying in 
the intersection of the parabolic line and the diagonal segment: (1,1) and (4,4), 
as seen in Fig. [3l 

All the computations described in this subsection can be actually executed in 
the TOy system and also formally represented in the cooperative goal solving 
calculus CCLNC(C). The formal representation of goal solving computations in 
CCLNC(C) performs quite many detailed intermediate steps. In particular, con- 
straints are transformed into a flattened form (without nested calls to primitive 
functions) before performing projections, and especial mechanisms for creating new 
bridges in some intermediate steps are provided. Detailed explanations and exam- 
ples are given in Section [3l 



1.3 Structure of the Paper 

To finish the introduction, we summarize the organization of the rest of the paper. 
Section [2] starts by presenting the main features of the CFLP scheme, including 
a mathematical formalization of constraint domains and solvers. The presentation 
follows flLopez-Praguas et al. 2007| , adding an explicit consideration of type disci- 
pline and an improved presentation of constraint domains, solvers and their formal 
properties. The rest of the section is new with respect to previous presentations of 
CFLP schemes: it discusses bridge constraints and the construction of coordina- 
tion domains, concluding with a presentation of a particular coordination domain 
C tailored to the cooperation of the domains 7i, 1Z and TT>. In the subsequent 
sections, C always refers to this particular coordination domain. 

Section [3] presents our proposal of a computational model for cooperative pro- 
gramming and goal solving in CFLP(C). Programs and goals are introduced, the 
cooperative goal solving calculus CCLNC(C) is discussed in detail, and its main 
formal properties (namely soundness and limited completeness w.r.t. the declarative 
semantics of CFLP(C) provided by the CFLP scheme) are presented. 

Section [4] sketches the implementation of the CCLNC(C) computational model 
on top of the TOy system ([Arenas et al. 2007)) . which is itself implemented on 



top of SICStus Prolog (SICStus Prolog 2007). The architectural components of the 



current TOy system are described and the extensions of TOy responsible for the 
treatment of bridges and projections according to the formal model provided by 
the previous section are briefly discussed. 

Section [5] discusses the practical use of the TOy system for solving problems 
involving the cooperation of the domains H, TZ and TT>. A significant set of bench- 
marks is analyzed in order to study how the cooperation mechanisms affect to the 
performance of the system, and a detailed comparison to the performance of the 
META-S tool is also presented. 

Section [6] is devoted to a discussion of related work, trying to give an overview of 
different approaches in the area of cooperative constraint solving. Section [7] sum- 
marizes the main results of the paper, points out to some limitations of the current 
TOy implementation, and presents a brief outline of planned future work. 
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The results reported in this paper are supported by the experimental results 
presented in Section [5] and a number of mathematical proofs, most of which have 
been collected in the Appendices IA.1I and IA.21 In the case of reasonings concern- 
ing type discipline, we have refrained from providing full details, that would be 
technically tedious and distract from the main emphasis of the paper. More de- 
tailed proofs could be worked out, if desired, by adapting the techniques from 
([Gonzalez- Moreno et al. 2001|) . 

2 Coordination of Constraint Domains in the CFLP Scheme 



The scheme presented in ( Lopez-Fraguas et al. 2007 ) serves as a logical and seman- 



tic framework for lazy Constraint Functional Logic Programming (briefly CFLP) 
over a parametrically given constraint domain. The aim of this section is to model 
the coordination of several constraint domains with their respective solvers using in- 
stances CFLP(C) of the CFLP scheme, where C is a so-called coordination domain 
built as a suitable combination of the various domains intended to cooperate. We use 
an enhanced version of the CFLP scheme, extending (|L6pez-Fraguas et al. 2007) 



with an explicit treatment of a polymorphic type discipline in the style of Hindlcy- 
Milncr-Damas and an improved presentation of constraint domains, solvers and 
their formal properties. In this setting, we discuss the three 'pure' constraint do- 
mains 7i, 1Z and J-T> along with their solvers. Next, we present bridge constraints 
and the construction of coordination domains, concluding with the construction of 
a particular coordination domain C tailored to the cooperation of the domains TL, 
1Z and TV, which is the topic of the rest of the paper. 



2.1 Signatures and Types 

We assume a universal signature fl — (TC, BT, DC, DF, PF) consisting of five 
pairwise disjoint sets of symbols, where 

• TC = Un6N TC n is a family of countable and mutually disjoint sets of type 
constructors, indexed by arities. 

• BT is a set of base types. 

• DC = UneN -DC™ is a family of countable and mutually disjoint sets of data 
constructors, indexed by arities. 

• DF = UneN DF n is a family of countable and mutually disjoint sets of defined 
function symbols, indexed by arities. 

• PF = UneN -P^ 1 ™ is a family of countable and mutually disjoint sets of primi- 
tive function symbols, indexed by arities. 

The idea is that base types and primitive function symbols are related to spe- 
cific constraint domains, while type constructors, data constructors and defined 
function symbols are related to user given programs. For each choice of a specific 
family of base types SBT C BT and a specific family of primitive function symbols 
SPF C PF, we will say that £ = (TC, SBT, DC, DF, SPF) is a domain specific 
signature. Note that any domain specific signature £ inherits all the type construc- 
tors, data constructors and defined function symbols from the universal signature 
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f2, since different programs over a given constraint domain of signature S might use 
them. All symbols belonging to the family DC U DF U SPF are collectively called 
function symbols. 

All along the paper we will work with a static type discipline based on the 
Hindley-Milner-Damas type system ( |Hindley 1969]IMilner 1978IIDamas and Milner 1982j) . 



A detailed study of polymorphic type discipline in the context of Functional Logic 
Programming (without constraints) can be found in ([Gonzalez-Mor eno et al. 2001[) . 
In the sequel we assume a countably infinite set TXhr of type variables. Types t G 
Types have the syntax r ::= A \ d | (c t t\ . . . t„) | (n, . . . ,r„) | (n — ► r ), where 
A G TXkr, d G SBT and Ct G TC n . By convention, parenthesis are omitted when 
there is no ambiguity, ct f n abbreviates Ct t\ . . . t„, and "— >" associates to the right, 
r„ — > t abbreviates ri — > • • • — > r n — > r. Types c t T n , (ri, . . . , r n ) and n — > ro 
are used to represent constructed values, tuples and functions, respectively. A type 
without any occurrence of "— >" is called a datatype. 

Type substitutions o- t ,8 t G TSub-z are mappings from TXar into Types, extended 
to mappings from Types into Types in the natural way. By convention, we write 
rat instead of at(r) for any type r. Whenever t' = Tat for some at, we say that r' 
is an instance of r (or also that r is more general than r') and we write t < t' . 

The set of type variables occurring in r is written tvar(r). A type r is called 
monomorphic iff iwar(r) = 0, and polymorphic otherwise. A polymorphic type r 
must be understood as representing all its possible monomorphic instances r'. 

Function symbols in any signature S are required to come along with a so-called 
principal type declaration, which indicates its most general type. More precisely, 

• Each n-ary c G DC n must have attached a principal type declaration of 
the form c :: r„ — > ct Ak, where n,k > 0, A\,...,Ak are pairwise differ- 
ent type variables, ct G TC k , t%,... ,t„ are datatypes, and UILi t var { T i) Q 
{Ai, . . . , Ak} (so-called transparency property). 

• Each n-ary / G DF n must have attached a principal type declaration of the 
form / :: f n — » r, where Ti (1 < i < n) and t are arbitrary types. 

• Each n-ary p G SPF n must have attached a principal type declaration of the 
form p :: r n — ► t, where ti, . . ., r„, r are datatypes and r is not a type 
variable. 

For the sake of semantic considerations, we assume a special data constructor 
(_L :: A) G DC , intended to represent an undefined value that belongs to any 
type. The type and data constructors needed to work with Boolean values and lists 
are also assumed to be present in the universal signature tt. We also assume that 
SPF 2 includes the polymorphic primitive function symbol == : : A -> A -> bool, 
that will be written in infix notation and used to express strict equality constraints 
in those domains where it is available. 

In concrete programming languages such as TOy ([Arenas et al. 2007}) and Curry 
(jHanus 2006j) . data constructors and their principal types are introduced by datatype 
declarations, the principal types of defined functions can be either declared or in- 
ferred by the compiler, the principal types of primitive functions are predefined and 
known to the users, and _L does not textually occur in programs. 
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Example 1 [Signatures and Types) 

In order to illustrate the main notions concerning signatures and types, let us 
consider the signature S underlying the program presented in Subsection ll.2l There 
we find: 

• Two base types int and real for the integer and real numeric values, respec- 
tively. 

• A miliary type constructor bool for the type of Boolean values, and a unary 
type constructor list for the type of polymorphic lists. The concrete syntax 
for list A is [A] . 

• [A] is a datatype, since it has no occurrences of the type constructor ->. 
Moreover, it is polymorphic, since it includes a type variable. Among the 
instances of [A] we can find [int] (for lists of integers) and [int -> int] 
(for lists of functions of type int -> int) . Note that an instance of a datatype 
must not be a datatype. 

• Two miliary data constructors false, true : : bool (for Boolean values); a 
miliary data constructor nil : : [A] (for the empty list); and a binary data 
constructor cons :: A -> [A] -> [A] (for nonempty lists). The concrete syn- 
tax for nil (resp. cons) is [] (resp. :), where : is intended to be used as an 
infix operator. 

• The principal types of the constructors in the previous item can be derived 
from the datatype declarations 

data bool = false I true 
data [A] = [] I (A : [A]) 
which are predefined and do not need to be included within programs. 

• In the program presented in Subsection 11.21 there are also type alias declara- 
tions, such as 

type dPoint = (int, int) 

type setOf A = A -> bool 

type region = setOf dPoint 
Such declarations are just a practical convenience for naming certain types. 
They cannot involve recursion, and the names of type alias so introduced are 
not considered to belong to the signature. 

• Defined function symbols of various arities, as e.g. isln, square S DF 2 . 
These two function symbols are binary because the rewrite rules given for 
them within the program expect two formal parameters at their left hand 
sides. In general, rewrite rules included in programs for defining the behaviour 
of symbols / £ DF n are expected to have n formal parameters at their 
left hand sides. In some cases, this n may not identically correspond to the 
number of arrows observed in the principal type of /. For instance, although 
square € DF 2 , the principal type is square : : int -> grid. The apparent 
contradiction disappears by noting that grid is declared as a type alias for 
(int, int) -> bool. Since the type constructor -> associates to the right, 
we have in fact square : : int -> (int, int) -> bool. 

• Primitive function symbols of various arities, as e.g. the binary primitives 
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#==, labeling, + and <=, and the ternary primitive domain. The concrete 
syntax requires #==, + and <= to be used in infix notation. Each primitive 
has a predefined principal type. For instance, #== : : int -> real -> bool, 
+ : : real -> real -> real and domain : : [int] -> int -> int -> bool. 

These declarations do not need to be included within programs. 

2.2 Expressions and Substitutions 

For any domain of specific signature E, constraint programming will use expressions 
which may have occurrences of certain values of base type. Therefore, in order to 
define the syntax of expressions we assume a S'BT-indexed family B — {Bd}deSBT, 
where each Bd is a non-empty set whose elements are understood as base values 
of type d. In the sequel, we will use letters u, v, .. . to indicate base values. By an 
abuse of notation, we will also write mg8 instead of u G Udessr 

Moreover, we also assume a countable infinite set \hr of data variables (disjoint 
from 1\hr and E), and we define applicative S- expressions e G Exps(B) over B 
with the syntax e ::= X | u | h \ (e±, . . . ,e„) | (eei), where X G Vir, u G B and 
he DC U DF U SPF. 

Expressions (ej., . . . , e„) represent ordered n-tuples, while expressions (e ei) - not 
to be confused with ordered pairs (e, ei) - stand for the application of the function 
represented by e to the argument represented by e±. Following a usual convention, 
we assume that application associates to the left, and we use the notation (ee n ) to 
abbreviate (e e\ . . . e n ). More generally, parenthesis can be omitted when there is no 
ambiguity. Applicative syntax is common in higher-order functional languages. The 
usual first-order syntax for expressions can be translated to applicative syntax by 
means of so-called curried notation. For instance, f(X,g(Y)) becomes (/ X (gY)). 

Expressions without repeated variable occurrences are called linear, variable-free 
expressions are called ground and expressions without any occurrence of _L are called 
total. Some particular expressions are intended to represent data values that do not 
need to be evaluated. Such expressions are called E-patterns t G Pat^(B) over B 
and have the syntax t ::= X \ u | . . . ,t„) | ct m \ ft m \ pt m , where X G \ar, 
u G B,c G DC n for some m < n, / G DF n for some n > m, and p G SPF" for some 
n > m. The restrictions concerning arities in the last three cases are motivated by 
the idea that an expression of the form ht n (where h G DF n USPF n ) is potentially 
evaluable and therefore not to be viewed as representing data. 

The set of all ground patterns over B is noted GPats(B). Sometimes we will 
write Uy,{B) in place of GPat^(B), viewing this set as the universe of values over 
B. The following classification of expressions is also useful: (Xe m ) (with X G Mir 
and m > 0) is called a flexible expression; while u G B and all expressions of the form 
(h e m ) (with h G DC U DF U SPF) are called rigid. Moreover, a rigid expression 
(he m ) is called passive iff h G DF n U SPF n and m < n, and active otherwise. 
Tuples (ei, . . . , e„) are also considered as passive expressions. The idea is that any 
passive expression has the outermost appearance of a pattern, although it might 
not be a pattern in case that any of its inner subexpressions is active. 

As illustrated by the program presented in Subsection 11.21 tuples are useful for 
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programming and therefore the tuple syntax is supported by many programming 
languages, including TOy. On the other hand, tuples can be treated as a particular 
case of constructed values, just by assuming data constructors tup n 6 DC n in 
the universal signature and viewing any tuple (ei, . . . ,e n ) as syntactic sugar for 
tup n e\ . . .e n . For this reason, in the rest of the paper we will omit the explicit 
mention to tuples, although we will continue to use them in examples. 

As usual in programming languages that adopt a static type discipline, all ex- 
pressions occurring in programs are expected to be well-typed. Deriving or checking 
the types of expressions relies on two kinds of information: Firstly, the principal 
types of symbols belonging to the signature, that we assume to be attached to the 
signature itself; and secondly, the types of variables occurring in the expression. In 
order to represent this second kind of information, we will use type environments 
r = {Xi :: ri, . . . , X n :: r„}, representing the assumption that variable Xi has 
type Tj for all 1 < i < n. Following well-known ideas stemming from the work of 
Hindley, Milner and Damas ( |Hindley 19691 IMilner 19781 IDamas and Milner 1982j) . 
it is possible to define type inference rules for deriving type judgements of the form 
E, r \~wt e :: r meaning that the assertion e :: r (in words, "e has type r") can 
be deduced from the type assumptions for symbols resp. variables given in E resp. 
r. The reader is referred to ([Gonzalez-Mor eno et al. 200 ip for a presentation of 
type inference rules well suited to Functional Logic Languages without constraints. 
Adding the treatment of constraints would be a relatively straightforward task. 
An expression e is called well-typed iff there is some type environment T such that 
E, r \~wt e :: t can be derived for at least one type r. Although this r is not 
unique in general, it can be proved that a most general type r (called the princi- 
pal type of e and unique up to renaming of type variables) can be derived for any 
well-typed expression e. In practice, principal types of well-typed expressions can 
be automatically inferred by compilers. 

We will write E, T \~wt e„ :: r„ to indicate that E, T \~wt e» :: Tj can be derived 
for all 1 < i < n, and E, T ^wt a :: t :: b to indicate that both E, T \~wt a :: t and 
E, r \~wt b :: t hold. An expression e is called well-typed iff E, T \~wt e :: t can be 
derived for some type r using the underlying signature E and some suitable type 
environment T. Sometimes we will write simply e :: r, meaning that E, F \~wt e :: r 
can be derived using the underlying E and some proper choice of T (which can be 
just if e is ground). 

For the sake of semantic considerations, it is useful to define an information or- 
dering C over Exp^,{B), such that eCe'is intended to mean that the information 
provided by e' is greater or equal than the information provided by e. Mathemati- 
cally, E is defined as the least partial ordering over Exps(B) such that ICe' for 
all e' £ Exp^(B) and (e ei) □ (e' e'i) whenever e C e' and e\ C e\. For later use, we 
accept without proof the following lemma. It is similar to the Typing Monotonicity 
Lemma in ([Gonzalez-M oreno et al. 2001j) and it says that the type of any expres- 
sion is also valid for its semantic approximations. It can be proved thanks to the 
fact that the undefined value J_ belongs to all the types. 
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Lemma 1 ( Type Preservation Lemma) 

Assume that E, T \~wt e' :: t and e C e' hold. Then E, T \~wt e :: r is also true. 

As part ol the definition ol signatures E we have required a transparency property 
for the principal types of data constructors. Due to transparency, the types of the 
variables occurring in a data term t can be deduced from the type of t. It is useful 
to isolate those patterns that have a similar property. To this purpose, we adapt 
some definitions from ([Gonzalez-Mo reno et al. 2001|) . A type which can be written 
as Tfn ^ T IS called m-transparent iff tvar(T m ) C tvar{r) and m-opaque otherwise. 
Also, defined function symbols / and primitive function symbols p are called m- 
transparent iff their principal types are m-transparent and m-opaque otherwise. 
Note that a data constructor c is always m-transparent for all m < or(c). 

Then, transparent patterns can be defined as those having the syntax t ::= X \ 
u | ct m | ft m | pt m , with X £ Vir, u e £>, c e DC 1 for some m < n, f € DF n for 
some n > m, and p € SPF n for some n > m, where the subpatterns ij in (c f m ), 
(/ ^m) and {pt m ) must be recursively transparent, and the principal types of both 
the defined function symbol / in (/ t m ) and the primitive function symbol p in 
(pt m ) must be m-transparent. 

For instance, assume a defined function symbol with principal type declara- 
tion snd : : A -> B -> B. Then snd is 1-opaque and the pattern (snd X) is also 
opaque. In fact, the principal type B -> B of (snd X) reveals no information on 
the type of X, and different instances of (snd X) keep the principal type B -> B, 
independently of the type of the expression substituted for X. Such a behaviour 
is not possible for transparent patterns, due to the Transparency Lemma stated 
without proof below. Similar results were proved in ([Gonzalez-Mo reno et al. 2001[) 
in a slightly different context. 

Lemma 2 ( Transparency Lemma) 

1. Assume a transparent pattern t and two type environments T\, T 2 such that 
E, Ti \~wt t :: t and E, T2 \~wt t :: r, for a common type r. 

Then T^X) = T 2 (X) holds for every X S var(t). 

2. Assume that E, T \~wt h Q>m t :: h b m holds for some m-transparent 
h E DC U DF U PF and some common type r. 

Then, there exist types such that E, T \~wt Q-i Ti :: bi holds for all 
1 < i < m. 

Substitutions a, 9 £ Sub^(B) over B are mappings from \hr to Pat^(B), extended 
to mappings from Exp-z: {B) to Exp^ (£>) in the natural way. For given e S Exps (£>) 
and a 6 Subs(B), we will usually write ea instead of c(e). Whenever e' = ecr for 
some substitution a, we say that e' is an instance of e (or also that e is more general 
than e') and we write e < e 1 . 

We write e for the identity substitution and o~9 for the composition of a and 9, 
such that e(o~9) — (ea)9 for any expression e. A substitution a such that 00 = a 
is called idempotent. The domain vdom(o~) and the variable range vran(o~) of a 
substitution are defined as usual: vdom(a) = {X 6 l&r | Xa ^ X} and vran(a) = 
Uxevdo,n(a) var(Xcr). 
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A substitution a is called finite iff vdom(o~) is a finite set, and ground iff Xo~ 
is a ground pattern for all X G vdom{a). In the sequel, we will assume that the 
substitutions we work with are finite, unless otherwise said. We adopt the usual 
notation a — \X\ i— > ti, . . . , X n i— ► i n }, whenever vdom(a) = {X\, . . . , X n } and 
Xi<r = for all 1 < z < n. In particular, e = { } = 0. We also write a[X \— > t] for the 
substitution cr' such that Xer' = t and Fcr' = IV for any variable Y G Mir \ {X}. 

For any set of variables X C "l&r we define the restriction a \x as the substitution 
a' such that vdom{cr') = X and cr'(X) = cr(X) for all X E X. We use the notation 
a =x 8 to indicate that a \x= \x, and we abbreviate a —^ r \x as a =\x ®- 

Given two substitutions a and 8, we define the application of 8 to a as the 
substitution a * 8 ~def 08 \ vdom(a). In other words, for any X € 1Ar, X(<r ★ 0) = 
Xad if X G vdom(cr) and X(a*6) = X otherwise. 

We consider two different ways of comparing given substitutions cr, a 1 G Subs, (B) : 

• a is said to be more general than a' over X C \hr (in symbols, a -<x o~') iff 
(70 =x o~' for some G Subs(B). We abbreviate cr diVir cr' as a < a' and 
O" ~<Vlt\X o-' as cr cr'. 

• cr is said to bear less information than a' over X C l&r (in symbols, cr cr') 
iff <r(X) E < 7 '(-^) f° r au X € X. We abbreviate cr Cy„, cr' as cr C cr' and 
cr Eur\A- cr' as cr Q\ x cr' . 

Example 2 [Well-typed Expressions) 

Let us consider the specific signature S and the family of base values B underlying 
the program presented in Subsection 11.21 There we find: 

• The sets of base values Bi n t = Z and B rea i = K- 

• Well-typed expressions such as square 4 (2,3) : : bool, RX-RY : : real, 
(RY-RX <= RYO-RXO) : : bool. 

• Well-typed patterns such as 3 : : int, 3.01 : : real, [X,Y] : : [int] , 
square 4 :: dPoint -> bool. Note that [X,Y] abbreviates (X:(Y:[])), 
as usual in functional languages that use an infix list constructor. 

• Finally, note that !_ C (0 : _L) C (0 : (1 : _L) ) C . . . illustrates the 
behaviour of the information ordering C when restricted to the comparison 
of patterns belonging to the universe Us(B). The list patterns of type [int] 
used in this example are not allowed to occur textually in programs because of 
the occurrences of the undefined value _L, but they are meaningful as semantic 
representations of partially computed lists of integers. 

2.3 Domains, Constraints and Solutions 

Intuitively, a constraint domain provides data values and constraints oriented to 
some particular application domain. Different approaches have been proposed for 
formalizing the notion of constraint domain, using mathematical notions borrowed 
from algebra, logic and category theory; see e.g. (jJaffar and Lassez 19 87; Sara swat 1992( 
IJaffar and Maher 1994( Uaffar et al. 1998"]) . The following definition is an elabora- 
tion of the domain notion given in ( |L6pez-Fraguas et al. 20071 ): 
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Definition 1 [Constraint Domain) 

A constraint domain of specific signature £ (shortly, E-domain) is a structure T> = 
(B v , {p v } P £SPf), where B v — {Bf}desBT is a S'ST-indexed family of sets of base 
values and the interpretation p v of each primitive function symbol p :: f n — » r in 
SPF n is required to be a set of (n + l)-tuplcs p v C U s (B v ) n+1 . In the sequel, 
we abbreviate U-ziBP) as (called the universe of values of 2?), and we write 
P^tn — > £ to indicate (£„,£) G p° . The intended meaning of u p v tn — > £" is that the 
primitive function p 25 with given arguments £ n can return a result £. Moreover, the 
interpretations of primitive symbols are required to satisfy four conditions: 

1. Polarity: For all p G SPF, u p v t n — > t" behaves monotonically w.r.t. the 
arguments t n and antimonotonically w.r.t. the result t. 

Formally: For all £ n , £'„,£,£' G Ux> such that p v t n — > £, t n C £'„ and £ □ £', 
p v t' n —> f also holds. 

2. Radicality: For all p G SPF, as soon as the arguments given to p° have 
enough information to return a result other than _L, the same arguments 
suffice already for returning a total result. 

Formally: For all £„, £ G Ut>, if p v t n — > £ then £ = _L or else there is some total 
£' G Wd such that p 15 ^ — * £' and £' □ £. 

3. Well-typedness: For all p G SPF, the behaviour of p° is well-typed w.r.t. 
any monomorphic instance of p's principal type. 

Formally: For any monomorphic type instance (r' n — > r') ^ (t„ — > r) and for 
all £„,£ G Z/fo such that S \~wt t n :: r' n and p^Jn — > £, the type judgement 
S hvi/T £ :: t' also holds. 

4. Strict Equality: The primitive == (in case that it belongs to SPF) is in- 
terpreted as strict equality over Ux>, so that for all t\,ti,t G Ut>, one has 
£i==- D £2 — ► £ iff some of the three following cases holds: 

(a) £i and £2 are one and the same total pattern, and true □ £. 

(b) £1 and £2 have no common upper bound in Uv w.r.t. the informa- 
tion ordering C, and false □ £. 

(c) £ = _L 

With this definition, it is easy to check that == D satisfies the polarity, radi- 
cality and well-typedness conditions. 

In Subsection 12.41 we will introduce the notion of solver, and we will see that 
the three domains Ti., 1Z and TT> mentioned in the introduction can be formalized 
according to the previous definition. In the rest of this subsection we discuss how 
to work with constraints over a given domain. 

For any given domain 2? of signature E, the set Ut> = U^(B V ) = GPatY,(B T ') 
is called the universe of values of the domain T>. We will also write Expi>, Pat-p 
and Sub-p in place of Exps(B T '), Pa£s(i3' D ) and Sub^,(B v ), respectively. Note that 
requirement 4. in Definition[T]imposes a fixed interpretation of == as the strict equal- 
ity operation over Ut>, for every domain T> whose specific signature includes 
this primitive. It is easy to check that the polarity, radicality and well-typedness 
requirements are satisfied by strict equality. The following definition will be useful: 
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Definition 2 ( Conservative Extension of a given Domain) 

Given two domains T>, V with respective signatures £ and V is called a con- 
servative extension of V iff the following conditions hold: 

1. £ C i.e. SBT C 5BT' and SPF C SPF'. 

2. For all cZ G SPT, one has S^' = S^. 

3. For all p G SPF n other than == and for every t n , t G Wr>, one has p v t n — > t 
iif p^tn 

As usual in constraint programming, we define constraints over a given domain 
T> as logical formulas built from atomic constraints by means of conjunction A 
and existential quantification 3. More precisely, constraints 8 G Con-D over the 
constraint domain V have the syntax 5 ::= a \ (Si A S 2 ) | 3X5, where a is any 
atomic constraint over T> and X G \hr is any variable. We allow two kinds of atomic 
constraints a over T>: a) and standing for truth (success) and falsity (failure), 
respectively; and b) atomic constraints of the form pe n — ► ! t with p G SPF n , where 
e„ G Expx>, t G Patx>, and i is required to be total (i.e., without any occurrences 
of _L). The intended meaning of pe n — >!t constrains the value returned by the call 
pe n to be a total pattern matching the form of t. 

By convention, constraints of the form pe n — >!true are abbreviated as pe„. 
Sometimes constraints of the formpe„ — ►! false are abbreviated asp' e„, using some 
symbol p' to suggest the 'negation' of p. In particular, strict equality constraints e\ 
== e2 and strict disequality constraints e\ /= e 2 are understood as abbreviations of 
e\ == e-i — >! true and e\ == e 2 — ►! false, respectively. The next definition introduces 
some useful notations for different kinds of constraints. 

Definition 3 (Notations for various kinds of constraints) 

Given two domains T>, T>' with respective signatures S and such that T>' is a 
conservative extension of 2?. Let SPF C SPF' be the sets of specific primitive 
function symbols of 2? and V , respectively. We define: 

1. AConx> C Con-D is the set of all atomic constraints over 2?. 

2. APCon-p C AConp is the set of all atomic primitive constraints over I?. By 
definition, a G APCon-p iff a has the form 0, ♦ or p t n — >! t, where Z„ G Pcrfx> 
are patterns. 

3. PConj) C Con-D is the set of all primitive constraints it over 2?. By definition, 
a constraint 7r G Con-p is called primitive iff all the atomic parts of 7r are 
primitive. Note that APConv = AConv n PConv- 

4. Conv \ SPF is the set of all SPF -restricted constraints over V . By defi- 
nition, a constraint S G Con V ' is called S'PP-restricted iff all the atomic 
parts of 5 have the form 0, ♦ or pe n — where p G SPF n . The subsets 
^PCon^ \ SPF C AConx>' f SPP C Conp' f S'PP are defined in the natu- 
ral way. In particular, APCon-p' \ SPF is the set of all the SPP-restricted 
atomic primitive constraints over V , which have the form or ♦ or p t n —>\t, 
with p G SPF n , t n ,te Patv and t total. 

A particular occurrence of a variable X within a constraint 5 is called free iff it is 
not affected by any quantification, and bound otherwise. In the sequel, we will write 
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var(S) (resp. fvar(S)) for the set of all variables having some occurrence (resp. free 
occurrence) in the constraint d. The notations var(A) and fvar(A) for a set of 
constraints A C Conv have a similar meaning. 

The type inference rules mentioned in Subsection 12.21 can be naturally extended 
to derive also type judgments of the form E, T hwr 5, meaning that the constraint 
S is well-typed w.r.t. the type assumptions for symbols resp. variables given in 
E resp. r. Sometimes we will simply claim that 6 is well-typed to indicate that 
E, r \~wt S can be derived using the underlying signature E and some suitable 
type environment T (which can be just if 8 has no free variables). 

The set of valuations Valv over the domain T> consists of all ground substitutions 
•q such that vran(r/) C Uv- Those valuations which satisfy a given constraint are 
called solutions. For those constraints S that include subexpressions of the form 
fe n for some / G DF n , the solutions of 5 depend on the behaviour of /, which is 
not included in the domain T>, but must be deduced from some user given program, 
as we will see in Section [3j However, the solutions of primitive constraints depend 
only on the domain T>. More precisely: 

Definition 4 (Solutions of Primitive Constraints) 

1. The set of solutions of a primitive constraint 7r G PConv is a subset SoId(tt) C 
Valv defined by recursion on the syntactic structure of 7r as follows: 

• Soh(O) = Val v ; Sol v (+) = 0. 

• Solx>(ptji — >!t) = {?/ G Val-p | (pt n —>\t)r] ground, p^trj] til: ^ total}. 

• Sol-p{if\ A 7r 2 ) = Solv{^\) n SoIt>(tt2)- 

• Sol-pfiXir) = {q G Val-p | exists^' G Solv{^)s.t.rj' v}- 

2. Any set II C PConx> is interpreted as a conjunction, and therefore 50/25(11) = 
rWenScMTr). 

3. The set of well-typed solutions of a primitive constraint it G PCon-p is a 
subset WTSoIx>(tt) C SoIx>(tt) consisting of all 77 G SoIt>(tt) such that nn is 
well-typed. 

4. Finally, for any II C PCon v we define WTSol v {U) = f| ffen WTSoI v (tt). 

Note that any solution n G SoIt>{k) must verify vdom{n) D fvar(jr). For later 
use, we accept the two following technical lemmata. The first one can be easily 
proved by induction on the syntactic structure of II and the second one is a simple 
consequence of the polarity properties of primitive functions. The notation (WT)Sol 
used in both lemmata is intended to indicate that they are valid both for plain 
solutions and for well- typed solutions. 

Lemma 3 (Substitution Lemma) 

For any given II C PConv, cr G Subv and rj G Valv, the equivalence r/ G 
(WT)Soh(ILa) ar) G (WT)Solv(tt) is valid. 

Lemma 4 (Monotonicity Lemma) 

For any given II C PConv and rj, rj' G Valv such that f)C?j' and 77 G (WT)Solv(n), 
one also has rf G {WT)Sol v {U). 
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A given solution r\ G Solz>{H) can bind some variables X to the undefined value 
_L Intuitively, this will happen whenever the value of X is not needed for checking 
the satisfaction of the constraints in II. Formally, a variable X is demanded by a set 
of constraints II C PCon-p iff n(X) ^ _L for all r\ G 5oZx> (II). We write dvarx>(n) 
to denote the set of all X G fvarili) such that X is demanded by II. 

In practice, CFLP programming requires effective procedures for recognizing 
'obvious' occurrences of demanded variables in the case that II is a set of atomic 
primitive constraints. We assume that for any practical constraint domain T> and 
any primitive atomic constraint tt G APConx> there is an effective way of com- 
puting a subset advar-p^n) C dvarT>(n). Variables X G odvar-p^) will be said 
to be obviously demanded by ir. We extend the notion to finite constraint sets 
IT C APCon-p by defining the set odvar-p (II) of all variables obviously demanded 
by II as Ujren odvarx>{ir)- In this way, it is clear that odvarv (II) C dvar-p (II) holds 
for any II C APCon-p] i.e., obviously demanded variables are always demanded. 
The inclusion is strict in general. 

In particular, for any constraint domain T> whose specific signature includes the 
strict equality primitive == and any primitive atomic constraint of the form 7r = 
(ii==i2 —*lt), odvarz>(Tr) is defined by a case distinction, as follows: 

• odvarT>(ti==t 2 -►! R) = {R}, if R G Vir. 

• odvar v (X==Y) = {X, Y}, if X, Y G Vir. 

• odvar v (X==t) = odvarj)(t==X) = {X}, if X G Vir and t £ Vir. 

• odvarj}(t\~t2) = 0, otherwise. 

• odvar v {X/=Y) = {X, Y}, if X,Y G Vir, X and Y not identical. 

• odvar v (X/=t) = odvar v (t/=X) = {X}, if X G Vir and t £ Vir. 

• odvar?)(t\l = ti) — 9, otherwise. 

The inclusion odvar-D^) C dvarxi{^) is easy to check, by considering the be- 
haviour of the interpreted strict equality operation == D '. The method for computing 
odvarj) (tt) for atomic primitive constraints based on primitive functions other than 
equality must be given as part of a practical presentation of the corresponding do- 
main T>. In the sequel, we will call critical to those variables occurring in II which 
are not obviously demanded, and we will write cvarx> (IT) = war (IT) \ odvarx> (II) for 
the set of all critical variables. As we will see in Section |3l goal solving methods for 
CFLP programming rely on the effective recognition of critical variables. There- 
fore, the proper behaviour of goal solving depends on well-defined methods for the 
computation of obviously demanded variables. 

In the rest of the paper we will often use constraint stores of the form S — II □ a, 
where IT C APConx> and a is an idempotent substitution such that vdom(a) n 
war(II) = 0. We will need to work with solutions of constraint stores, possibly 
affected by an existential prefix. This notion is defined as follows: 

Definition 5 (Solutions of Constraint Stores) 

1. Sol v (3Y(ILUa)) = {i]e Val v | exists rj' G Sol v {naa), s.t.rj' =\yv}- 

2. Soh(UDa) = Sol v (U) DSol{a). 

3. Sol (a) = {rj G Val-p | r) = crn} 

(Note that rj — ar\ holds iff Xr\ = Xar\ for allX G vdom(a)). 
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4. WTSol v {3Y(n □ a)) = {77 G Vah | ex. 77' G WTSWz>(II □ <t), s.t. 77' 77}. 

5. ^T5oip(nD(7) = {77 G 5oZp(nn<r) I (n □ a) * r) is well- typed}, where 
(II □ a) * 77 = de / II77 □ (cr * 77). 

Example 3 [Constraints and Their Solutions) 

Let us now illustrate different notions concerning constraints by referring again to 
the motivating example from Subsection ll.2l The domain C underlying this example 
is a 'hybrid' domain supporting the cooperation of three 'pure' domains named TL, 
1Z and TV, as we will see in Subsections 12.41 and 12.51 For the moment, note that 
C allows to work with four different kinds of constraints, namely bridge constraints 
and the specific constraints supplied by TL, 1Z and TV, as explained in Section [1] 

1. Concerning well- typed constraints, we note that the small program in this 
example is well-typed. Therefore, all the constraints occurring there are also 
well-typed. For instance: 

• domain [X,Y] N is well-typed (w.r.t. any type environment which 
includes the type assumptions X :: int, Y :: int, N :: int). 

• RY+RX <= RYO+RXO is also well-typed (w.r.t. any type environment 
which includes the type assumptions RY : : real, RX : : real, RYO 
: : real, RXO : : real). 

Of course, the signature underlying the example allows to write constraints 
such as domain [X,Y] true 3.2, which cannot be well-typed in any type 
environment. Due to static type discipline, the compiler will reject programs 
including ill-typed constraints. 

2. Concerning constraint solutions, note that computing by means of the co- 
operative goal solving calculus presented in Section [3] eventually triggers the 
computation of solutions for primitive constraints. As already discussed in 
Subsection 11.21 solving Goal 2 eventually leads to the following set II of 
primitive constraints (understood as logical conjunction): 

X #== RX, Y #== RY, 

RY >= d-0.5, RY-RX <= 0.5, RY+RX <= n+0.5, 
domain [X,Y] n, labeling [] [X,Y] . 

II happens to be the union of three sets of primitive constraints corresponding 
to the three lines above: A set of two bridge constraints Hm, a set of three real 
arithmetical constraints Hr, and a set of two finite domain constraints Hf- 
Therefore, SolcQI) = SoIc(Hm) H SoI c (Rr) n Sol c {Il F ). As we have seen in 
Subsection 1 1.2i the only possibility for 77 G Solc(n) is 77 (X) = 77 (Y) = d, and 
the computation proceeds with the help of constraint solvers and projections, 
among other mechanisms. 

3. Concerning obviously demanded variables, let us remark that all the variables 
occurring in the constraint set II shown in the previous item are obviously 
demanded. This will become clear from the discussion of the domains TL, 1Z 
and TV in Subsection 12.41 
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4. Concerning critical variables, note that a variable may be critical either be- 
cause it is demanded but not obviously demanded, or else because it is not de- 
manded at all. For instance, variables A and B are demanded but not obviously 
demanded by the strict equality constraint (A, 2) == (1 ,B) . Therefore, they 
are critical variables. To illustrate the case of critical but not demanded vari- 
ables, consider the primitive constraint 7r = L /= X:Xs. Due to the definition 
of 'obvious demand' for strict disequality constraints, variable L is obviously 
demanded by tt, while X and Xs are not obviously demanded, and therefore 
critical. Moreover, it can be argued that neither X nor Xs is demanded by tt. 
Variable X is not demanded because there exist solutions n £ SoI-d(tt) such 
that ?7(X) = _L (cither with f?(L) ~ [] or else with ry(L) = t : ts such that 
?7(Xs) is different from ts). Variable Xs is not demanded because of similar 
reasons. 

2-4 Pure Domains and their Solvers 

In order to be helpful for programming purposes, constraint domains must provide 
so-called constraint solvers, which process the constraints arising in the course of 
a computation. For some theoretical purposes, it suffices to model a solver as a 
function which maps any given constraint to one of the three different values true, 
false or unknown; see e.g. (jJaffar et al. 1998]) . In practice, however, solvers are 
expected to have the ability of reducing primitive constraints to so-called solved 
forms, which are simpler and can be shown as computed answers to the users. 
As discussed in the introduction (see in particular Subsection ll.2|) , the constraint 
domain underlying many practical problems may involve heterogeneous primitives 
related to different base types. In such cases, it may be not realistic to expect that 
a single solver for the whole domain is directly available. 

In the sequel, we will make a pragmatic distinction between pure constraint do- 
mains which are given 'in one piece' and come equipped with a solver, and hy- 
brid constraint domains which are built as a combination of simpler domains and 
must rely on the solvers of their components. In the rest of this subsection we 
give a mathematical formalization of the notion of solver tailored to the needs of 
the CFLP scheme, followed by a presentation of TL, 1Z and TT) as pure domains 
equipped with solvers. In the case of TZ and TT>, we limit ourselves to describe their 
most basic primitives, although other useful facilities are available in the TOy im- 
plementation. A proposal for the construction of so-called coordination domains as 
a particular kind of hybrid domains will be presented in Subsection 12.51 

2.^.1 Constraint Solvers 

For any pure constraint domain T> we postulate a constraint solver which can reduce 
any given finite set II of atomic primitive constraints to an equivalent simpler form, 
while taking proper care of critical variables occurring in II. Since the value of a 
critical variable X may be needed by some solutions of II and irrelevant for some 
other solutions, we require that solvers have the ability to compute a distinction of 
cases discriminating such situations. 
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Definition 6 (Formal Requirements for Solvers) 

A constraint solver for the domain D is modeled as a function solve 13 which can be 
applied to pairs of the form (II, X), where II C APCon-p is a finite set of atomic 
primitive constraints and X C cvar-r> (II) is a finite set including some of the critical 
variables in II, where the two extreme cases X = and X — cvarx>(H) are allowed. 
By convention, we may abbreviate solve (II, 0) as solve (II). We require that any 
solver invocation solve (H,X) returns a finite disjunction Vj=i □ er,-) of 

existentially quantified constraint stores, fulfilling the following conditions: 

1. Fresh Local Variables: For all 1 < j < k: (TljOaj) is a store, Yj = 
var{Y\j Dcj) \ var(TV) are fresh local variables and vdom(o~j) U vran(aj) C 
var(U) llFj. 

2. Solved Forms: For all 1 < j < k: IF, □ Oj is in solved form w.r.t. X. By 
definition, this means that solve (Hj , X) = IF,- □ e. 

3. Safe Bindings: For all 1 < j < k and for all X £ A" n vdom(aj): o~j(X) is a 
constant. 

4. Discrimination: Each computed ^-solved form Ilj □ Oj (1 < j ' < fc) must 
satisfy: Either X n odvar-D (II,) ^ or else <Y n war (Ilj) = (i.e., either 
some critical variable in X becomes obviously demanded, or else all critical 
variables in X disappear). 

5. Soundness: Sol v (U) D \J k j=1 Sol v (3Y j(n^ □ a j)). 

6. Completeness: WTSol v (U) C [J j fe =1 WTSol-D^Yj^j □ ctj)). 

Moreover, solve is called an extensible solver iff the solver invocation solve (II, A") 
is defined and satisfies the conditions listed in this definition not just for II C 
APCon-D and X C cvarj) (II), but more generally for II C APCon-p' \ SPF and 
^ C CTarx)'(n), where I?' is any conservative extension of T>. The idea is that an 
extensible solver can deal with constraints involving the primitives in T> and values 
described by patterns over arbitrary conservative extensions of T>. 

The presentation of goal solving in Section [3] will discuss the proper way of 
choosing a set X of critical variables for each particular solver invocation. The idea 
is that X should include all critical variables which are waiting to be bound to the 
result of evaluating some expression at some other place within the goal. This idea 
also motivates the safe bindings condition. 

Operationally, the alternatives within the disjunctions returned by solver invoca- 
tions are usually explored in some sequential order with the help of a backtracking 
mechanism. Assuming that solve (JL, X) = V_y=i ^Vjfllj □ o~j), we will sometimes 
use the following notations: 

• n H - solve™ 3Y 7 (n / □ a') to indicate that 3F 7 (n' □ a') is 3Fj(IL; □ tr,) for some 
1 < j < k. In this case we will speak of a successful solver invocation. 

• II H- so ;„ e B M to indicate that k = 0. In this case we will speak of a failed 
solver invocation, yielding the obviously unsatisfiable store ■ = ♦□£. 

As defined above, a constraint store II □ a is said to be in solved form w.r.t. a set 
of critical variables X (or simply in solved form if X = 0) iff solve (II, X) = II □ £. 
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In practice, solved forms can be recognized by syntactical criteria, and a solver 
invocation solve® (II, X) is performed only in the case that II □ a is not yet solved 
w.r.t. X . Whenever a solver is invoked, the soundness condition requires that no new 
spurious solution (whether well-typed or not) is introduced, while the completeness 
condition requires that no well-typed solution is lost. In practice, any solver can 
be expected to be sound, but completeness may hold only for some choices of the 
constraint set II to be solved. Demanding completeness for arbitrary (rather than 
well-typed) solutions would be still less realistic. The solvers of interest for this 
paper suffer some limitations regarding completeness, as explained in Subsections 
[2X21 12X31 and [2A41 below. 

From a user's viewpoint, a solver can behave as a black-box or as a glass-box. 
Black-box solvers can just be invoked to compute disjunctions of solved forms, 
but users cannot observe their inner workings, in contrast to the case of glass- 
box solvers. Users can define glass-box solvers by means of appropriate tools, such 
as Constraint Handling Rules (jPriihwirth 1998]). In this paper we propose to use 
store transformation systems as a convenient abstract technique for specifying the 
behaviour of glass-box solvers. A store transformation system (briefly sts) over the 
constraint domain T> is specified as a set of store transformation rules (briefly strs) 
RL that describe different ways to transform a given store II □ a w.r.t. a given 
set X of critical variables. The notions and notations defined below are useful for 
working with stss. Some of them refer to a selected set of strs noted as 1ZS. 

• II □ a Vrv,x n' □ a' indicates that the store II □ a can be transformed into 
II' □ a' in one step, using one of the available strs. This notation can be also 
used to indicate a failing transformation step, writing the inconsistent store 
■ = ♦ □ e in place of IT □ a 1 . 

• II □ a H-j) x n' □ <r' indicates that II □ a can be transformed into II' □ a' in 
finitely many steps. 

• The store II □ a is called 1ZS- irreducible iff there is no str RL e 1ZS that can 
be applied to transform II □ a. Note that this is trivially true if 1ZS is the 
empty set. If 1ZS is the set of all the available strs, the store II □ a is called 
simply irreducible (or also a ^-solved form). 

• Una H-p X \IL' □ a' indicates that II □ a H-|, x II' □ a' holds, and moreover, 
the final store II' □ a 1 is irreducible. 

Assume a given sts over T> such that for any finite II C APConx> and any 
X C cvar v (U), the set ST V {^,X) = {IT □ a' | IIDe H-J,^! IT Oct'} is finite. 
Then the solver defined by the sts can be specified to behave as follows: 

solve {Ti, X) = Y{3F 7 (n'ncr') | IlW e SJpTl, X),^ = uar(nW) \ var(U)} 

Once solve® has been so defined, the notation II H- so i ve T> 3Y'(U' Ua') actually 
happens to mean that II □ e Vr^ x \ IF □ <r' and Y' = var (II' □ a') \ var (II). There- 
fore, the symbols ^~ so i ve j> and 1^^, x \ should not be confused, but have related 
meanings. The following definition specifies different properties of store transfor- 
mation systems that are useful to check that the corresponding solvers satisfy the 
conditions stated in Definition [6] 
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Definition 7 [Properties of Store Transformation Systems) 

Assume a store transformation system over T> whose transition relation is Vr-p .x, 
and a selected set 1ZS of strs. Then the sts is said to satisfy: 

1. The Fresh Local Variables Property iff II □ a W~t>, x II' □ cr' implies that 
II' □ cr' is a store, Y' = var(H' □ cr') \ var(H □ cr) are fresh local variables, 
and cr' = oo\ for some substitution o~\ (responsible for the variable bindings 
created at this step) such that vdom(o\) U vran(o~\) C var(H) U Y'. 

2. The Safe Bindings Property iff II □ a x II' □ a' implies that o\ (X) is 
a constant for all X E X C\vdom(a\), where a' — aa± as in the previous item. 

3. The Finitely Branching Property iff for any fixed II □ a there are finitely 
many IT □ a' such that IT □ a W-- D> x IT' □ a'. 

4. The Termination Property iff there is no infinite sequence {IT □ <Tj | i 6 N} 
such that Hi □ di Vrv. x Ilt+i ^ o~i+i for all igN. 

5. The Local Soundness Property iff for any X>-store II □ er, the union 

[j{Sol TI {3Y T (Il'na')) | II □ cr H-z>, ^ n' □ <t', F 7 = var(U' □ o-')\w(n □ cr)} 

is a subset of Sc^-p (II □ cr) . 

6. The Local Completeness Property for 7^.5-free steps iff for any P-store 
II □ a which is 7^.5- irreducible but not in <Y-solved form, WTSol-p (II □ &) is 
a subset of the union 

[j{WTSol v (3Y 7 (W a a')) \ UUa \h v ^ x U'Da^Y 7 = varfjl'da') \var(Uaa)} 

If 7^.5 is the empty set (in which case all the stores are trivially 1ZS- irreducible) 
this property is called simply local completeness. 

In the case of an extensible solver, the six conditions listed in this definition must 
be checked for any conservative extension T>' of V and any set II of 5*PF-restricted 
atomic primitive constraints over D' . 

Assume a solver solve defined by means of a given sts with transition relation 
Vrv, x and a selected set 1ZS of strs. If the sts is terminating, the following recursive 
definition makes sense: A given store II □ a is hereditarily IZS-irreducible iff IT □ a is 
US- irreducible and all the stores II' □ a' such that II □ a Yt-d x II' □ cr' (if any) are 
also hereditarily 1ZS- irreducible. A solver invocation solve (II, X) is called IZS-free 
iff the store IT □ e is hereditarily 7?.iS-irreducible. This notion occurs in the following 
technical lemma (proved in Appendix lA.Ijl , which can be applied to ensure that 
solve satisfies the requirements for solvers listed in Definition [6l 

Lemma 5 (Solvers defined by means of Store Transformation Systems) 

Any finitely branching and terminating £>-store transformation system verifies: 

1. iS^ : "d(II, X) is always finite, and hence solve is well defined and trivially 
satisfies the solved forms property. 

2. solve has the fresh local variables resp. safe bindings property if the store 
transformation system has the corresponding property. 

3. solve is sound if the store transformation system is locally sound. 
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4. solve is complete for 7^<S-free invocations if the store transformation system 
is locally complete for 72.<S-free steps. In the case that TZS is empty, this 
amounts to say that solve is complete if the store transformation system is 
locally complete. 

Note that this lemma can be used for proving global properties of extensible 
solvers, provided that the sts can work with constraint stores II □ c, where II is 
a finite set of SP-F-restricted atomic primitive constraints over some arbitrary 
conservative extension T>' of T>, and the local properties required by the lemma 
hold for any such £>'. 

In the rest of this paper, we will work with the three pure domains Ti, J-T> and 
TZ introduced in the following sections. We will rely on black-box solvers for TZ and 
TT> provided by SICStus Prolog and we will define an extensible glass-box solver 
for Ti using the store transformation technique just explained. 

2. 4- 2 The Pure Constraint Domain Ti 

The Herbrand domain Ti supports computations with symbolic equality and dise- 
quality constraints over values of any type. Formally, it is defined as follows: 

• Specific signature £ = (TC, SBT, DC, DF, SPF), where SBT is empty 
and SPF includes just the strict equality operator == : : A -> A -> bool. 

• Interpretation ==H , defined as for any domain whose specific signature in- 
cludes ==. 

Recall Definition [2] and note that a conservative extension of Ti is any domain T> 
whose specific signature includes the primitive ==. Such a V will be called a domain 
with equality in the sequel. The {==}-restricted constraints over a given domain 
with equality are also called extended Herbrand constraints. As already explained 
in Subsection 12.31 atomic Herbrand constraints have the form e% == ei —>■!<, strict 
equality constraints e\ == ei abbreviate e\ == ei — >\ true, and strict disequality 
constraints abbreviate e\ == ei — ■>! false. 

Obviously demanded variables (and thus critical variables) for primitive extended 
Herbrand constraints are computed as explained in Subsection 12.31 An extensible 
Herbrand solver must be able to solve any finite set n C APCon-p \ {==} of 
atomic primitive extended Herbrand constraints, w.r.t. any X C cvar-r>{U) of cri- 
tical variables. Roughly speaking, the solver proceeds by symbolic decomposition 
and binding propagation transformations. More precisely, we define an extensible 
glass-box solver for Ti by means of the store transformation technique explained in 
Subsection l2.4.11 using the transformation rules for Ti stores shown in TableQ] Each 
of these rules has the form it, n □ a Vrn. x II' □ <r' and indicates the transformation 
of any store tt, n □ a, which includes the atomic constraint 7r plus other constraints 
n; no sequential ordering is intended. We say that 7r is the selected atomic constraint 
for this transformation step. The notation t m ==s m in transformation H3 abbrevia- 
tes t\ == s±, . . . , t m == s m and will be used at some other places. All the stss make 
sense for arbitrary extended Herbrand constraints, which ensures extensibility of 
the 7i-solver. Note that transformations H3 and H7 involve decompositions. An 
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application of H3 or H7 is called opaque iff h is m-opaque in the sense explained in 
Subsection 12. 2i in which case the new constraints resulting from the decomposition 
may become ill-typed. Note also that an application of transformation H13 may 
obviously lose solutions. An invocation solve H (II, X) of the 7i-solver is called safe iff 
it has been computed without any opaque application of the store transformation 
rules H3 and H7 and without any application of the store transformation rule 
H13. More formally, soive H (II, X) is a safe invocation of the W-solver iff it is 
WZS-hee, where WIS is the set {OH3, OH7, H13} consisting of H13 and the 
unsafe instances OH3 and OH7 corresponding to opaque applications of H3 and 
H7, respectively. 



HI (t == s) ->! R, II □ a W-h,x (t == s, II)<ti □ o-o-i where ai = {i{H true}. 
H2 (t == s) ->! R, n □ a ti- n ,x it /= s, U)ai □ aai where oi = {R i-v false}. 
H3 ht m == hs m , II □ a Vth,x t m ~s m , II □ a 
H4 t == X, II □ a Vrn.x X == t, II □ a if t is not a variable. 
H5 X == t, n □ a Vrn,x tot(t), Ucn □ aai if X <£ X, X var(t), X t, 
where a 1 — {X t}, tot(t) abbreviates Ayguarft) (Y==Y). 

H6 X == t, n □ a Yr H ,x ■ if X G uor(t), X / t. 
H7 /il m /= hs m , II □ ct Yrn.x (t« /= Si, II □ a) for each 1 < i < m. 
H8 ht n /= h's m , II □ a tt~u,x II □ o if ft ^ ft' or n ^ m. 
H9 t /= i, n □ tr H-tt,x ■ if £ G Ur U DC U 73 F U SPF. 
H10 t /= X, II □ o- H-w,x X /= £, II □ o if t is not a variable. 
Hll X/= ct n , IIDo \f~H,x (Z i /=t i ,U)a 1 aaa 1 if X^<¥, cG7X7 n and X n var{ct n )^% 
where l<i<n (non-deterministic choice), cti={X^ cZ n }, Z n fresh variables. 
H12 X /= ct n , n □ a H-k,a- Ho-1 O aai if X £ A", c G DC" and A" n uar(cl„) / 
where cti = {X i— ► dZ m }, c G DC", d G DC m , d =fi c, d belongs to the same 
datatype as c, Z m fresh variables. 

H13 X /= ht m , Tin a Vth.x ■ ii X £ X , X C\ var(ht m ) and h £ DC m . 



Table 1. Store Transformations for solve 

The idea of using equality and disequality constraints in Logic Programming 
stems from Colmerauer (IColmerauer 19841 IColmerauer 1990|) . The problem of sol- 
ving these constraints, as well as related decision problems for theories involv- 
ing equations and disequations, has been widely investigated in works such as 
(jLassez et al. 1988|IM"aher 1988|IComon and Lescanne 19"89jlComon 1991(IFernandez 1992( 
IBuntine~a nd Biirckert 1994), among others. These papers assume the classical alge- 
braic semantics for the equality relation, and propose methods for solving so-called 
unification and disunification problems bearing some analogies to the transforma- 
tion rules shown in Table [TJ However, there are also some differences, because strict 
equality in CFLP is designed to work with lazy and possibly non-deterministic 
functions, whose behaviour does not correspond to the semantics of equality in 
classical algebra and equational logic, as argued in QRodriguez-Artalejo 2001[ ). Note 
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in particular transformation H5, which introduces constraints of the form Y == Y 
in 7i-solved forms. These are called totality constraints, because a valuation r\ is 
a solution of Y == Y iff rj{Y) is a total pattern. An approach to disequality con- 
straints close to our semantic framework can be found in (| Arenas et al. 1994)) . but 
no formalization of a Herbrand solver is provided. 

The following theorem ensures that the sts for H-stores can be accepted as a 
correct specification of an extensible glass-box solver for the domain TL, which is 
complete for safe solver invocations. 

Theorem 1 {Formal Properties of solve H ) 

The sts with transition relation Vru, x is finitely branching and terminating, and 
therefore 

solve n {Il, X) = V-pF^n' □ a') | II' □ a' G 5^(11, X), Y 7 = var(W □ a')\var{U)} 

is well defined for any domain with equality V, any finite II C APCon(T>) \ {==} 
and any X C cvarx>(Jl). Moreover, for any arbitrary choice of a domain T> with 
equality, solve H satisfies all the requirements for solvers enumerated in Definition 
|6l except that the completeness property may fail for some choices of the constraint 
set II C APCon(V) f {==} to be solved, and is guaranteed to hold only if the solver 
invocation solve n (IL, X) is safe (i.e., {OH3, OH7, H13}-free). 

The proof of the previous theorem is rather technical and can be found in Ap- 
pendix [A. 11 At this point, we just make a few remarks related to the discrimination 
and completeness properties, that may help to understand some differences between 
our 7i-solver and more classical methods for solving unification and disunification 
problems. On the one hand, transformations Hll and H12 are designed to en- 
sure the discrimination property while preserving completeness w.r.t. well-typed 
solutions. On the other hand, transformation H13 trivially ensures discrimination, 
but it sacrifices completeness because it fails without making sure that no well- 
typed solutions exist. This corresponds to situations unlikely to occur in practice 
and such that no practical way of preserving completeness is at hand. The other 
two failing transformations given in Table [T] (namely H6 and H9) respect com- 
pleteness, because they are applied to unsatisfiable stores. Finally, the other cases 
where completeness may be lost correspond to unsafe decomposition steps per- 
formed with the opaque instances OH3 and OH7 of the sirs H3 and H7. Due to 
the termination property of the TL-sts, it is decidablc wether a given 7i-storc II □ a 
is hereditarily £Y7?.<S-irreducible, in which case no opaque decompositions will oc- 
cur when solving the store. However, computations in the cooperative goal solving 
calculus presented in Section [3] can sometimes give rise to 7i-stores whose reso- 
lution involves opaque decomposition steps. Due to theoretical results proved in 
(jGonz alcz-Mor eno et al. 2001 j) . the eventual occurrence of opaque decomposition 
steps during goal solving is an undecidable problem. In case that opaque decompo- 
sitions occur, they should be signaled as warnings to the user. 

Example 4 (Behaviour of solve H ) 

In order to illustrate the behaviour of solve' H , consider the disequality constraint L 
/= X:Xs discussed in item 4. of Example [3] Remember that variable L is obviously 
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demanded, while variables X and Xs are both critical. Therefore, there are four 
possible choices for the set X of critical variables to be used within the solver 
invocation, namely: 0, {X}, {Xs} and {X, Xs}. Let us discuss these cases one by one. 

• Choosing X = means that the solver is not asked to discriminate w.r.t. 
any critical variable. In this case, solve n (L/=X : Xs,0) returns L/=X:Xs □£, 
showing that L/=X:Xs is seen as a solved form w.r.t. the empty set of critical 
variables. 

• Choosing X = {X} asks the solver to discriminate w.r.t. the critical variable 
X. solve H (L/=X : Xs,{X}) returns a disjunction of alternatives 

(0 D{L i — * []}) V (X'/= XD{L i ► X' : Xs'}) V (Xs'/= Xs D{L ^ X' : Xs'}) 

whose members correspond to the three different stores II' □ a' such that 
the step L/=X:Xs De ^«,{x} II' □ a' can be performed with transformation 
H12. Since these stores are solved w.r.t. {X}, no further transformations are 
required. Note that X does not occur in the first and third alternatives, while 
it has become obviously demanded in the second one. In this way, the dis- 
crimination property required for solvers is fulfilled. 

• For each of the two choices X = {Xs} and X = {X, Xs}, it is easy to check 
that the solver invocation solve n {L/=X : Xs, X) returns the same disjunction 
of three alternatives as in the previous item, and the discrimination property 
is also fulfilled w.r.t. the chosen set X in both cases. 

2.4.3 The Pure Constraint Domain TZ 

The TZ domain supporting computation with arithmetic constraints over real num- 
bers is a familiar idea, used in the well-known instance CLP {TV} of the CLP scheme 
( Jaffa r et al. 19 92). In the context of our CFLP framework, a convenient formal 
definition of the domain TZ is as follows: 

• Specific signature E = (TC, SBT, DC, DF, SPF), where SBT = {real} 
includes just one base type whose values represent real numbers, and SPF 
includes the following binary primitive symbols, all of them intended to be 
used in infix notation: 

— The strict equality operator == : : A -> A -> bool. 

— The arithmetical operators +, -, *, / :: real -> real -> real. 

— The inequality operator <= : : real -> real -> bool. 

• Set of base values £>2 al = M. 

• Interpretation == K , defined as for any domain whose specific signature in- 
cludes ==. 

• Interpretation defined so that for all ti, t%, t s Un'- 

t\ + n t2 — ► t is defined to hold iff some of the following cases holds: 

Either t±, t 2 and t are real numbers, t being equal to the addition of t\ and 

t 2 , or else t = _L. The interpretations of -, * and / are defined analogously. 
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• Interpretation <= n , denned so that for all t\, t%, t £ U-ji: 

ti <= n t2 — *• i is denned to hold iff some of the following cases holds: 
Either t±, t 2 are real numbers such that t\ is less than or equal to i 2 , and t = 
true; or else t±, i 2 are real numbers such that t\ is greater than and t = 
false; or else t = JL 

Atomic ^-constraints have the form e\ e 2 —*lt, where is the strict equa- 
lity operator or the inequality operator or an arithmetical operator. An atomic 
7£-constraint is called proper iff is not the strict equality operator, and an ex- 
tended Herbrand constraint otherwise. As already explained in previous sections, 
strict equality constraints e\ == e 2 and strict disequality constraints e\ /= e.% can be 
understood as abbreviations of extended Herbrand constraints. Moreover, various 
kinds of inequality constraints can also be defined as abbreviations, as follows: 

• ei < e 2 =def e 2 <= e\ — >■! false e\ <= e 2 =def £\ <= e 2 — ►! true 

• ei > e 2 =def ei <= e 2 — ►! false ei >= e 2 =d e f e 2 <= e\ — >! true 

Concerning the solver solve 11 , we expect that it is able to deal with 7?.-specific 
constraint sets IT C APCon-ji consisting of atomic primitive constraints ir of the 
two following kinds: 

• Proper ^-constraints t\ i 2 — where is either the inequality operator 
or an arithmetical operator. 

• 7?.-spccific Herbrand constraints having the form t\ == < 2 or t\ 1= ti, where 
each of the two patterns t\ and i 2 is either a real constant value or a variable 
whose type is known to be real prior to the solver invocation. 

For any finite 7\L-specific n C APConn, it is clear that dvar-ji (II) = var (II). 
Therefore, it is safe to define odvar-jiiji) — var(H) and thus cvar-ji(H) = 0. Conse- 
quently, invocations to solve 71 can be assumed to be always of the form solve 11 (II, 0) 
(abbreviated as soZve 7 ^ (II)), and the discrimination requirements for critical vari- 
ables become trivial. Assuming that solve 71 is used under the restrictions described 
above and implemented as a black-box solver on top of SICStus Prolog, we are con- 
fident that the postulate stated below is a reasonable one. In particular, we assume 
that SICStus Prolog solves 7?.-specific Herbrand constraints in a way compatible 
with the behaviour of the extensible 7i-solver described in the previous subsection. 

Postulate 1 [Assumptions on the 1Z Solver) 

solve 71 satisfies five of the six properties required for solvers in Definition [5] (namely 
Fresh Local Variables, Solved Forms, Safe Bindings, Discrimination and Soundness) , 
although the Completeness property may fail for some choices of the 7?.-specific 
n C APCon-ji to be solved. Moreover, whenever n C APCon-n is 7?.-specific and 
II Vr so i ve n 3Y'(U' □ a'), the constraint set n' is also 7\L-specific, and for all X £ 
vdom(a'): Either cr'(X) is a real value, or else X and cr'(X) belong to uar(II). 
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Example 5 {Behaviour of the 1Z Solver) 

Let us now illustrate the behaviour of solved by considering the set of primitive 
atomic constraints RY >= d-0 . 5 , RY-RX <= 0.5, RY+RX <= n+0 . 5 occurring in 
item 2. of Example [3] The solver invocation solve n (Jln) returns one single alter- 
native H' R □ e with = Ilfl U {RY <= d+0 . 5}. In this case, the new constraint RY 
<= d+0 . 5 has been inferred by adding the two former constraints RY-RX <= 0.5 
and RY+RX <= n+0 . 5 and taking into account that n = 2*d. In other cases, the 1Z 
solver can perform other inferences by means of arithmetical reasoning valid in the 
mathematical theory of the real number field. In general, solved forms computed 
by solvers help to make more explicit the requirements on variable values already 
'hidden' in the constraints prior to solving (as the upper bound RY <= d+0 . 5 in 
this example). 

2-4-4 The Pure Constraint Domain J-T> 

The idea of a TT> domain supporting computation with arithmetic and finite do- 
main constraints over the integers is a familiar one within the CLP community, see 
e.g. ( |van Hentenryck et al. 1 994; van Hentenryck et al. 1998] ) . In the context of our 
CFLP framework, a convenient formal definition of the domain TV is as follows: 

• Specific signature S = (TC, SET, DC, DF, SPF), where SET = {int} 
includes just one base type whose values represent integer numbers, and SPF 
includes the following primitive symbols: 

— The strict equality operator == : : A -> A -> bool. 

— The arithmetical operators #+, #-, #*, #/ :: int -> int -> int. 

— The following primitive symbols related to computation with finite do- 
mains: 

— domain:: [int] -> int -> int -> bool 

— belongs:: int -> [int] -> bool 

— labeling:: [labelType] -> [int] ->bool, where labelType is 

an enumerated datatype used to represent labeling strategies. 

— The inequality operator #<= : : int -> int -> bool. 

• Set of base values = Z. 

• Interpretation ==- FV , defined as for any domain whose specific signature in- 
cludes ==. 

• Interpretation #+ :FV , defined so that for all t\, ti, t 6 Uj^r>: 

t\ #+- FV t2 — > t is defined to hold iff some of the following cases holds: 
Either t\, ti and t are integer numbers, t being equal to the addition of t\ 
and t2, or else t = _L The interpretations of #-, #* and #/ are defined 
analogously. 

• Interpretation domain^ 23 , defined so that for all t\, £2, £3, t G Ufti'- 
domain^ 17 t\ £2 £3 — * t is defined to hold iff some of the following cases holds: 
Either ti and tj, are integer numbers a and b such that a < b, t\ is a non 
empty finite list of integers belonging to the interval a..b and t — true; or else 
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t 2 and t 3 are integer numbers a and b such that a < b, t\ is a non empty list 
of integers some of which does not belong to the interval a..b and t = false; 
or else t 2 and £3 are integer numbers a and b such that a > b and t = false; 
or else t = _L. 

• Interpretation belongs^ 1 ', defined so that for all t\, t 2l t G Uft>'- 
belongs^ t\t 2 — * t is defined to hold iff some of the following cases holds: 
Either t\ is an integer, t 2 is a finite list of integers including t\ as element, 
and t = true; or else t\ is an integer, t 2 is a finite list of integers not including 
t\ as element, and t — false; or else t = _L. 

• Interpretation labeling^, defined so that for all t\, t 2 , t G Uft>'- 
labeling-^ 1 ' £1 ^2 —> t is defined to hold iff some of the following cases holds: 
Either t\ is a defined value of type labelType, t 2 is a finite list of integers, 
and t = true; or else t = _L. 

• Interpretation #< =:FV , defined so that for all t\, t 2 , t G Uj=t>' 

ti #<= J,r ' D t2 — > £ is defined to hold iff some of the following cases holds: 
Either ti, t 2 are integer numbers such that t\ is less than or equal to t 2 , and 
t = true; or else t\, t 2 are integer numbers such that t\ is greater than t 2 , 
and t — false; or else t — J_. 

Atomic JTI)-constraints include those of the form e\ e 2 — >! t, where is either 
the strict equality operator or the inequality operator or an arithmetical operator, as 
well as domain constraints domain e\ e 2 e-^ — >! t, membership constraints belongs 
ei e 2 — >!£ and labeling constraints labeling e\ e 2 — At. Atomic JTD-constraints 
are called extended Herbrand if they have the form e\ ==e 2 — >!£, and proper TT>- 
constraints otherwise. As already explained in previous sections, strict equality con- 
straints ei == e 2 and strict disequality constraints e\ /= e 2 can be understood as ab- 
breviations of extended Herbrand constraints. Moreover, various kinds of inequality 
constraints can also be defined as abbreviations, as follows: 

• ei #< e 2 —def g 2 #<= ei — >! false e\ #<= e 2 —def ei #<= e 2 — >! true 

• ei #> e 2 —def ei #<= e 2 — >! false e\ #>= e 2 =d e / e 2 #<= ei — >! true 

Concerning the solver solve :FV ', we expect that it is able to deal with JFD-spccific 
constraint sets II C APCon^ consisting of atomic primitive constraints 7r of the 
two following kinds: 

• Proper TV atomic primitive constraints (which may be t\ t 2 — >! £, where 
is either an integer arithmetical primitive or an inequality primitive, or 
primitive domain, membership and labeling constraints). 

• JFD-specific Herbrand constraints having the form t\ == t 2 or t\ /= t 2 , where 
each of the two patterns t\ and t 2 is either an integer constant value or a 
variable whose type is known to be int prior to the solver invocation. 

For any finite .FX'-specific n C APConyr Vj it is clear that dvar^D (II) = var(H). 
Therefore, it is safe to define odvar^D (n) = var(H) and thus cvarp-Dfil) = 0. 
Consequently, invocations to solve jr ' D can be assumed to be always of the form 
solve :FT '(II, 0) (abbreviated as solve- F ' D (II)) , and the discrimination requirements 
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for critical variables become trivial. Assuming that solve^ is used under the re- 
strictions described above and implemented as a black-box solver on top of SICStus 
Prolog, we are confident that the postulate stated below is a reasonable one. In par- 
ticular, we assume that SICStus Prolog solves JFP-specific Herbrand constraints in 
a way compatible with the behaviour of the extensible 7i-solver described in the 
previous subsection. 

Postulate 2 {Assumptions on the TT> Solver) 

solve 37 " satisfies five of the six properties required for solvers in Definition[6] (namely 
Fresh Local Variables, Solved Forms, Safe Bindings, Discrimination and Soundness) , 
although the Completeness property may fail for some choices of the .F2?-specific 
IT C APConyr-p to be solved. Moreover, whenever II C APConjr V is JPD-specific 
and II VrsoiveF-D BY' (II' □ a'), the constraint set II' is also JFD-specific, and for all 
X 6 vdom{a'): Either cr'(X) is an integer value, or else X and cr'{X) belong to 
war (II). 

In particular, labeling constraints are solved by a systematic enumeration of pos- 
sible values for certain integer variables. Therefore, solve :FV is unable to solve a 
labeling constraint tt unless the current constraint store includes domain or mem- 
bership constraints for all the variables occurring in tt. The next example shows a 
typical situation. 

Example 6 [Behaviour of the TT> Solver) 

In order to illustrate the behaviour of solve F ' D , let us consider the set of primitive 
atomic constraints lip = {domain [X,Y] n, labeling [] [X,Y]} occurring 
also in item 2. of Example [3l The solver invocation solve~ FV (JIf) must solve the 
conjunction of a domain constraint and a labeling constraint, both involving the 
integer variables X and Y. The solver proceeds by enumerating all the possible values 
of both variables X and Y within their respective domains (determined in this case 
by the domain constraint domain [X,Y] n) and returns a disjunction of (n+1) 2 
alternatives, each of which describes one single solution: 

(0 n{x i — > 0, Y i — v 0}) V • • • V (0 D{X i — > ri, Y i — ► n}) 

In general, solving labeling constraints can give rise to very expensive enumera- 
tions of solutions, unless the finite domains of the integer variables involved have 
been pruned by some precedent computation. As already discussed in Subsection 
11.21 the efficiency of solving the constraint system occurring in item 2. of Example 
|3] can be greatly improved by cooperation among the the domains TC, 1Z and TV. 
We propose to use the coordination domains defined in the next subsection as a 
vehicle for domain cooperation in CFLP programming. 

2.5 Coordination Domains 

Coordination domains C are a kind of 'hybrid' domains built from various compo- 
nent domains T>i, intended to cooperate. The construction of coordination domains 
also involves a so-called mediatorial domain A4, whose purpose is to supply bridge 
constraints for communication among the component domains. In practice, the 
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component domains will be chosen as pure domains equipped with solvers, and the 
communication provided by the mediatorial domain will also benefit the solvers. 

Mathematically, the construction of coordination domains relies on a joinabi- 
lity condition. Two given constraint domains D% and T> 2 with specific signatures 
Ei = (TC, SBTi, DC, DF, SPFi) and E 2 = (TC, SBT 2 , DC, DF, SPF 2 ), 
respectively, are called joinable iff the two following conditions hold: 

• SPFi n SPF2 C {==}; i.e., the only primitive function symbol p allowed to 
belong both to SPFi and SPF 2 is the strict equality operator ==. 

• For every common base type d G SBTi n SBT 2 , one has B^ 1 = B^ 2 . 

The amalgamated sum S = T>\ ®T> 2 of two joinable domains T>\ and T> 2 is defined 
as a new domain with signature £ = {TC, SBT^SB^, DC, DF, SPF 1 USPF 2 ), 
constructed as follows: 

• For i = 1, 2 and for all d G SBT % : Bf = 

(no conflict will arise for those d G SBTi n SBT 2 , because of joinability) 

• For i = 1,2, for all p G SPFi, p other than ==, and for all t n , t £ Lis- 
P S t n — ► t is defined to hold iff one of the two following cases holds: 

Either t = _L or else there exist t' n , t' G Ux, i such that t' n C i n , t' □ t and 
p v ^ n -» i'. 

Note that the value universe underlying an amalgamated sum S = T>\ © X>2 is 
a superset of Z/r^ for i = 1,2. The interpretation of == in S will behave as defined 
for any constraint domain, see Subsection 12.31 For primitive functions p G SPFi 
other than ==, the definition of p is designed to obtain an extension of p Vi which 
satisfies the technical conditions required by Definition [TJ 

The amalgamated sum T>\ © • ■ • © T> n of n pairwise joinable domains T>± (1 < 
i < n) can be defined analogously. The following definition and theorem guarantee 
the expected behaviour of amalgamated sums as conservative extensions of their 
components. The proof of the theorem is given in Appendix IA.1I 

Definition 8 (Domain specific constraints and truncation operator) 

Assume 5 = T>x © • • • © V n of signature S, constructed as the amalgamated sum of 

n pairwise joinable domains £>,; of signatures Sj. Let any 1 < i < n be arbitrarily 

fixed. 

1. A set LT C APCon-Di is called T>i-specific iff every valuation 77 G Vols such 
that r\ G Sols(H) satisfies r/(X) G Uv t for all X G var(U). Note that the 
7?.-specific and ^P-specific sets of constraints previously introduced in sub- 
sections 12.4.31 and 12.4.41 are also specific in the sense just defined. 

2. Consider the information ordering C over Us. The T>i- truncation of a given 
S value t G Us is defined as the C-greatest I?i value | t \v t ^ M-D t which 
satisfies | t |x> 4 E ^ so that any other value t G Zip; such that t C t 
must satisfy t C | t |x>. . An effective construction of | t \x> i from i can be 
obtained by substituting _L in place of any subpattern of t which has any of 
the two following forms: a basic value u which does not belong to U-Pi, or a 
partial application of a primitive function which does not belong to T>i specific 
signature. Note that \ t\x> i =t\i and only if t G U-p^ 
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3. The T>i- truncation of a given S- valuation 77 G Vals is the T>i valuation | 77 |x>i 
defined by the condition | r\ |p 4 (X) = \ T](X) |p j; for all X G 1Ar. Note that 
I 77 |x> ; = 77 if and only if 77 G Valvt- 

Theorem 2 [Properties of Amalgamated Sums) 

For any <S = Pi ffi • • • © P„ of signature E constructed as the amalgamated sum of 
n pairwise joinable domains Pj of signatures Ej (1 < i < ra): 

1. S is well-defined as a constraint domain; i.e., the interpretations of primitive 
function symbols in S satisfy the four conditions listed in Definition [T] from 
Subsection [2.31 

2. iS is a conservative extension of T>i for all (1 < % < n); i.e., for all 1 < i < n, for 
any p G SPF™ 1 other than ==, and for every t m ,t £ Ud^ one has p Di t m — > /; 
iff p 5 Z m -> i. 

3. For all 1 < i < n, for any set of primitive constraints II C APCon-r> i and for 
every valuation t] G Val Vz , one has r, G (IFT)SoZ P! (n) iff 77 £ (WT)SHs(II). 

4. For all 1 < i < n, for any set of Pi-specific primitive constraints IT C 
APCon-r> i and for every valuation 77 G Vals, one has 77 G (WT)Sols(H) 
iff I 77 l^e (WT)Sol Vi (IL). 

Note that amalgamated sums of the form 7i®V are always possible, and give rise 
to compound domains that can profit from the extensible Hcrbrand solver. However, 
in order to construct more interesting sums tailored to the communication among 
several pure domains, so-called mediatorial domains are needed. Given 77, pairwise 
joinable domains Pi with specific signatures E^ = (TC, SBTi, DC, DF, SPFi) 
(1 < i < n), a mediatorial domain for the communication among Pi, ... , P„ is de- 
fined as any domain M with specific signature E = {TC, SBT , DC, DF, SPF a ) 
constructed in such a way that the following conditions are satisfied: 

• SBT a C U^ =1 SBT h and SPF n SPF t = for all 1 < i < n. 

• For each d G SBT and for any 1 < i < n such that d G SBT t , B^ 4 = B d \ 
(no confusion can arise, since the domains Pi are pairwise joinable). 

• Each p £ SPFq is a so-called equivalence primitive #==d i ,d j with declared 
principal type di — > <ij —> 600Z, for some 1 < i,j • < n and some di G SBTi, 
dj G SSI}. 

• Moreover, each equivalence primitive #==d i ,d J is used in infix notation and 
there is an injective partial mapping inj diidj ■ B d * — > £> d J used to define the 
interpretation of #== ( ; i ,(i j in M as follows: For all s,t,r G Wx, s #== d vl d . t — > r 
iff some of the three cases listed bellow holds: 

1. s G dom(inj dzidj ), t G /3 dj J , t = inj dudj (s) and irue □ r. 

2. s G dom(inj d ^ dj ), t G , £ 7^ inj diidj (s) and /aZse □ r. 

3. r = _L 

Equivalence primitives #== ditdj allow to write well-typed atomic mediatorial con- 
straints of the form a #== di , dj b — A c, using expressions a :: dj, b :: dj and c :: 600L 
Constraints of the form a #==d i ,d j b — >! true resp. a #==d i ,d j & — ►! false are abbre- 
viated as a #==d i .d j b resp. a #/==d i ,d j b and called bridges and antibridges, respec- 
tively. The usefulness of bridges for cooperative goal solving in CFLP has been 
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motivated in the introduction and will elaborated when presenting the coopera- 
tive goal solving calculus CCLNC(C) in Section [3] Antibridges and mediatorial 
constraints a #==d ijC L b — >! R, where R is a variable, can also occur in CCLNC(C) 
computations, but they are not so directly related to domain cooperation as bridges. 

Each particular choice of injective partial mappings injd^dj and their correspond- 
ing equivalence primitives #==<i j)t L gives rise to the construction of a particular me- 
diatorial domain M, suitable for communication among the T>i. Moreover, it is clear 
by construction that the n + 1 domains A4, V\, . . . , V n are pairwise joinable, and 
it is possible to build the amalgamated sum C = M. © V\ © • • • © V n . This 'hybrid' 
domain supports the communication among the domains X\ via bridge constraints 
provided by M. Therefore, M is called a coordination domain for T>\, . . . , V n . 

In practice, it is advisable to include the Herbrand domain Ti. as one of the 
component domains T>i when building a coordination domain C. In application 
programs over such a coordination domain, the Ti. solver is typically helpful for 
solving symbolic equality and disequality constraints over user defined datatypes, 
while the solvers of other component domains Vi whose specific signatures include 
the primitive == may be helpful for computing with equalities and disequalitics 
related to 2Vs specific base types. 

2. 6 The Coordination Domain C = M@Ti® TV © TZ 

In this subsection, we explain the construction of a coordination domain for coope- 
ration among the three pure domains TI, TV and TZ. 

First, we define a mediatorial domain M. suitable to this purpose. It is built with 
specific signature E = {TC, SBT , DC, DF, SPF ), where SBT = {int,real} 
and SPFq = {#== int. real}- The equivalence primitive #~i n t,real is interpreted with 
respect to the total injective mapping inji n t,real Z — > R, which maps each inte- 
ger value into the equivalent real value. In the sequel, we will write #== in place 
of #==int,reai when referring to this equivalence primitive. We will use the same 
abbreviation for writing mediatorial constraints. 

Next, we use this mediatorial domain for building C — M. © Tt © TV © TZ. In 
the rest of the paper, C will always stand for this particular coordination domain, 
whose usefulness has been motivated in Section [T] and will become more evident 
in Section [3] Note that bridges X #== RX and antibridges X #/== RX can be useful 
just as constraints; in particular, X #== RX acts as an integrality constraint over the 
value of the real variable RX. More importantly, in Section[3]the mediatorial domain 
C will serve as a basis for useful cooperation facilities, including the projection of 
TZ constraints to the TV solver (and vice versa) using bridges, the specialization 
of Ti constraints to become 7?.-specific or .FP-specific in some computational con- 
texts, and some other special mechanisms designed for processing the mediatorial 
constraints occurring in computations. 

In particular, computation rules for simplifying mediatorial constraints will be 
needed. Although Ai is not a 'pure' domain, simplifying A4-constraints is most 
conveniently thought of as the task of a A'f-solver. This solver is expected to deal 
with .M-specific constraint sets II C APCoum consisting of atomic primitive con- 
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straints 7r of the form t #==s — >! 6, where b is either a variable or a boolean constant 
and each of the two patterns t and s is either a variable or a numeric value of the 
proper type (int for t and real for s). For any finite set II C APCoum of such 
Al-specific constraints, it is clear that duarx(II) = var(TT). Therefore, it is safe to 
define odvarM (II) = var(H) and thus cvarM (II) = 0. We define a glass-box solver 
solve M by means of the store transformation technique explained in Subsection 
12.4. li using the strs for A^-stores shown in Table [2j Due to the absence of critical 
variables, one-step transformations of .M-stores do not depend on a parametrically 
given set X of critical variables and have the form w, II □ a Vtm n' □ a', indicating 
the transformation of any store 7r, II □ a, which includes the atomic constraint 7r 
plus other constraints II; no sequential ordering is intended. We say that ir is the 
selected atomic constraint for this transformation step. 



Ml (t #== s) ->! B, II □ a Ytm (t #== s, n)<n □ aa x 

if t ettrUZ, s £\arUR, B G \hr, where cri = {B i-> true}. 

M2 (t #== s) — >! B, II □ cr H _/v( (t #/== s, n)cri □ am 

if i G Xhr U Z, s G \ar U R, 5 G Ur, where oi = {B h-> false}. 

M3 X #==ll', n □ a Vr M Rm □ crcri 

if u' G R, and there is it G Z such that u #== M u' — > true, where cri = {X i— > u}. 

M4 X #== u', n □ o- W- M ■ 

if u' G R, and there is no u G Z such that it #==' M it' — + true. 

M5 u #== n □ a W- M n<7i □ aai 

if u G Z and u'gR is so chosen that u #== M u — > true, where ai = i— > it'}. 

M6 u #== u', II □ a W- M n □ a if u G Z, u' G R, and it #== A1 it' -> true. 

M7 u #== it', II □ a W~ M ■ if u G Z, u' G R, and u #==- M u' -> /aZse. 

M8 u #/== it', II □ a tt-M II D a if it G Z, u' G R, and u #==' M u' -> /aZse 

M9 it #/== u', M □ a W-m ■ if u G Z, u' G R, and u *== M u -» trite. 



Table 2. Store Transformations for solve 

The following theorem ensures that the sis for .M-stores can be accepted as a 
correct specification of a glass-box solver for the domain Ai. 

Theorem 3 [Formal Properties of the Ai Solver) 

The sts with transition relation W~m is finitely branching and terminating, and 
therefore 

solve M {n) = yiBY'iTl' □ a') | H 7 □ a' G 5^(11), F 7 = var(n' □ er') \ uar(II)} 

is well defined for any finite II C APCon^ of .M-specific constraints. The solver 
solve satisfies all the requirements for solvers enumerated in Definition [6] More- 
over, whenever n C APConj^ is ./Vf-specific and II W~ S olve M 

3Y'(WDa'), the 
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constraint set II' is also .A/f-specific and <j'(X) is cither a boolean value, an integer 
value or a real value for all X £ vdom(o~'). 

The proof is omitted, because it is completely similar to that of Theorem [T] but 
much easier. In fact, the sts for .M-stores involves no decompositions. Actually, this 
sts is finitely branching, terminating, locally sound and locally complete. Therefore, 
Lemma [5] can be applied. 

The framework for cooperative programming and the cooperative goal solv- 
ing calculus CCLNC(C) presented in Section [3] essentially rely on the coordina- 
tion domain C just discussed, and the instance CFLP(C) of the CFLP scheme 
flLopez-Fraguas et al. 2007[ ) provides a declarative semantics for proving the sound- 
ness and completeness of CCLNC(C). As we will see, some cooperative goal solving 
rules in CCLNC(C) rely on the identification of certain atomic primitive Herbrand 
constraints 7r as J-T'-spccific or 7\L-spccific, respectively, on the basis of the medi- 
atorial constraints available in a given A4-store M. The notations M h 7r in TD 
and M h 7r in TZ defined below serve to this purpose. 

Definition 9 (Inference of domain- specific extended Herbrand constraints) 
Assume a mediatorial store M and a well-typed atomic extended Herbrand con- 
straint 7r having the form t\ == ti or t\ /= taj where each of the two patterns t\ 
and t% is either a numeric constant v or a variable V. Then we define: 

1. M h 7r in TT> (read as 'M allows to infer that ir is .FD-specific') iff some of 
the three following conditions holds: 

(a) t\ or t% is an integer constant. 

(b) t\ or ti is a variable that occurs as the left argument of the opera- 
tor #== within some mediatorial constraint belonging to M. 

(c) t\ or t2 is a variable that has been recognized to have type int by 
some implementation dependent device. 

2. M h 7T in TZ (read as £ M allows to infer that ir is 7?.-specific') iff some of the 
three following conditions holds: 

(a) t\ or t2 is a real constant. 

(b) t\ or t2 is a variable that occurs as the right argument of the 
operator #== within some mediatorial constraint belonging to M. 

(c) t\ or t% is a variable that has been recognized to have type real 
by some implementation dependent device. 

3 Cooperative Programming and Goal Solving in CFLP(C) 

This section presents our cooperative computation model for goal solving. After 
introducing programs and goals in the first subsection, the subsequent subsections 
deal with goal solving rules, illustrative computation examples, and results con- 
cerning the formal properties of the computation model. 

Our goal solving rules work by transforming initial goals into final goals in solved 
form which serve as computed answers, as in the previously published Constrained 
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Lazy Narrowing Calculus CLNC(V) ( |L6pez-Fraguas et al. 2004 ), which works over 



any parametrically given domain T> equipped with a solver. We have substan- 
tially extended CLNC(T>) with various mechanisms for domain cooperation via 
bridges, projections and some more ad hoc operations. The result is a Cooperative 
Constrained Lazy Narrowing Calculus CCLNC(C) which is sound and complete 
(with some limitations) w.r.t. the instance CFLP(C) of the generic CFLP scheme 
( |L6pez-Fraguas et al. 2007] ) . For the sake of typographic simplicity, we have re- 
stricted our presentation of CCLNC(C) to the case C = M © H © TV © 1Z, 
although it could be easily extended to other coordination domains, as sketched in 
our previous paper (jEstevez-Martm et al. 2007]) . 

3.1 Programs and Goals 

CF LP (C)- programs are sets of constrained rewrite rules that define the behavior of 
possibly higher-order and/or non-deterministic lazy functions over C, called program 
rules. More precisely, a program rule Rl for a defined function symbol / G DF£ 
with principal type / :: ~f n — > r has the form ft n — > r 4= A, where t n is a linear 
sequence of patterns, r is an expression, and A is a finite conjunction Sx, . . . , 5 m of 
atomic constraints 5i S AC one- Each program rule Rl is required to be well- typed, 
i.e., there must exist some type environment T for the variables occurring in Rl 
such that E, V \~wt ti Ti for all 1 < i < n, S, T \~wt r :: t and S, T \~wt o~i 
for all 1 < i < m. 

The left-linearity requirement is quite common in functional and functional logic 
programming. As in constraint logic programming, the conditional part of a pro- 
gram rule needs no explicit occurrences of existential quantifiers. A program rule 
Rl is said to include free occurrences of higher- order logic variables iff there is some 
variable X which does not occur in the left-hand side of Rl but has some occur- 
rence in a context of the form X e m (with m > 0) somewhere else in Rl. A program 
V includes free occurrences of higher-order logic variables iff some of the program 
rules in V does. 

As in functional languages such as Haskell ( [Peyton- Jones 200"2| ), our programs 
rules can deal with higher-order functions and are not expected to be always ter- 
minating. Moreover, in contrast to Haskell and most other functional languages, 
we do not require program rules to be confluent. Therefore, some program defined 
functions can be non- deterministic and return several values for a fixed choice of ar- 
guments in some cases. As a concrete example of typed CFLP(C)-program written 
in the concrete syntax of the TOy system, we refer to the program rules presented 
in Subsection 11.21 

Programs are used to solve goals using a cooperative goal solving calculus which 
will be described in subsections 13.21 [3T31 and [3T4l below. Goals over the coordination 
domain C have the general form G = 3U. P □ C □ M □ H □ F □ R, where the 
symbol □ is interpreted as conjunction and: 

• U is a finite set of so-called existential variables, intended to represent local 
variables in the computation. 

• P is a set of so-called productions of the form e\ — > ti, . . . , e m — > t m , where 
ei G Expc and ti e Pate for all 1 < i < m. The set of produced variables of G 
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is defined as the set pvar(P) of variables occurring in t\ . . . t m . During goal 
solving, productions are used to compute values for the produced variables 
insofar as demanded, using the goal solving rules for constrained lazy narrow- 
ing presented in Subsection 13.21 We consider a production relation between 
variables, such that X ^-p Y holds iff X, Y e pvar(P) and there is some 
1 < i < m such that X £ var(ei) and Y S var(ti). 

• C is the so-called constraint pool, a finite set of constraints to be solved, 
possibly including active occurrences of defined functions symbols. 

• M = Hm d o~m is the mediatorial store, including a finite set of atomic primi- 
tive constraints ITj/ C APCotim and a substitution o~m- We will write Bm C 
Hm for the set of all tt G II a/ which are bridges t #== s, where each of the 
two patterns t and s may be either a variable or a numeric constant. 

• H = Hh n o~h is the Herbrand store, including a finite set of atomic primitive 
constraints IT# C APCon-j-c and a substitution an. 

• F = Hp □ o~p is the finite domain store, including a finite set of atomic primi- 
tive constraints TLf C APCon^z) and a substitution a p. 

• R = Hji □ ap is the real arithmetic store, including a finite set of atomic 
primitive constraints 11^ C APConji and a substitution a p. 

A goal G is said to have free occurrences of higher- order logic variables iff there 
is some variable X occurring in G in some context of the form Xe rn , with m > 0. 
Two special kinds of goals are particularly interesting. Initial goals just consist of a 
well-typed constraint pool C. More precisely, the existential prefix U, productions 
in P, and stores M , H, F and R are empty. Solved goals (also called solved forms) 
have empty P and C parts and cannot be transformed by any goal solving rule. 
Therefore, they are used to represent computed answers. We will also write ■ to 
denote an inconsistent goal. 

Example 7 (Initial and Solved Goals) 

Consider the initial goals Goal 1, Goal 2 and Goal 3 presented in TOy syntax in 
Subsection 1 1.21 for the choice d = 2, n = 4. When written with the abstract syntax 
for general C-FLP(C)-goals they become 

1) □ bothln (triangle (2, 2.75) 4 0.5) (square 4) (X,Y) □□□□ 

2) □ bothln (triangle (2, 2.5) 2 1) (square 4) (X,Y) □□□□ 

3) □ bothln (triangle (2, 2.5) 8 1) (square 4) (X,Y) □□□□ 

The expected solutions for these goals have been explained in Subsection 11.21 A 
general notion of solution for goals will be defined in Subsection [321 The resolution 
of these example goals in our cooperative goal solving calculus CCLNC(C) will 
be discussed in detail in Subsection 13.51 The respective solved forms obtained as 
computed answers (restricted to the variables in the initial goal) will be: 

1) ■ 

2) □□□□ (0 a {X ^ 2,Y ^ 2}) □ 

3) □□□□ (0 □ {X h-> 0,Y ^ 2}) □ 

□ □□□ (0 □ \x i — > 1, Y i — ► 2}) □ 

□ □□□ (0 □ \x i — > 2, Y i — > 2}) □ 
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□ □□□ (<) a {X ^ 3,Y ^ 2}) □ 

□□□□ (OnjiH^H 2}) □ 

The goal solving rules of the CCLNC(C) calculus presented in the rest of this 
section has been designed as an extension of an existing goal solving calculus for the 
CFLP scheme ( [Lopez- Fraguas et al. 2004| ), adding the new features needed to sup- 
port solver coordination via bridge constraints. In contrast to previous related works 
such as dLoogen et al. 1993[|Alrtoy et al. 1994||Antoy et al. 2000[ lde l Vado-Virseda 20031 
Idel Vado-Virseda 2005| Idel Vado-Virseda 2007[) . we have omitted the use of so- 
called definitional trees to ensure an optimal selection of needed narrowing steps. 
This feature could be easily added to CCLNC(C) following the ideas from (jdel Va do-Virse da 2005)) . 
but we have decided not do so in order to avoid technical complications which do 
not contribute to a better understanding of domain cooperation. Moreover, the de- 
sign of CCLNC(C) is tailored to programs and goals having no free occurrences 
of higher-order logic variables. As shown in ( Gonzalez- Moreno et al. 20 01). goal 
solving rules for dealing with free higher-order logic variables give rise to ill-typed 
solutions very often. If desired, they could be easily added to our present setting. 

Let us finish this subsection with a brief discussion of some technical issues needed 
in the sequel. The set odvar(G) of obviously demanded variables in a given goal G 
is defined as the least subset of var(G) which satisfies the two following conditions: 

1. odvar{G) includes odvarM (Um), odvaruiJ^H), odvar^-jy(ILp) and odvar-jiiJ^B.) 
which are defined as explained in Subsections 12.31 and 12.41 

2. X € odvar(G) for any production (X~a~k —* t) £ P such that k > and either 
t £ Vir or else t e odvar(G). 

Note that odvar(G) boils down to odvar^ (11^-) U oduar-^ (Il^f ) \J odvar jr V (Jl F ) U 
odvar-jz (JIr) in the case that G has no free occurrences of higher-order variables. 
Productions e — * X such that e is an active expression and X ^ odvar(G) is a not 
obviously demanded variable are called suspensions, and play an important role 
during goal solving. 

Certain properties are trivially satisfied by initial goals and kept invariant through 
the application of goal transformations. Such goal invariant properties include those 



formalized in previous works as e.g. (Lopez-Fraguas et al. 2004 1: Each produced 



variable is produced only once, all the produced variables must be existential, the 
transitive closure 3>p of the relation between produced variables must be irreflexive, 
and no produced variable occurs in the answer substitutions. Other goal invariants 
are more specific of our current cooperative setting based on the coordination do- 
main C: 

• The domains of the substitutions o~m, o~Hi o~p and o~r are pairwise disjoint. 

• For any store S in G, the application of erg causes no modification to the goal. 

• For any X 6 vdom(o~M), &m(X) is either a boolean value, an integer value 
or a real value. 

• For any X G vdom(ap), ctf(X) is either an integer value or a variable occur- 
ring in lip. 
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• For any X £ vdom(on), or(X) is either a real value or a variable occurring 
in U R . 

These properties remain invariant through goal transformations because of The- 
orem [3] and Postulates [2] and HJ and also because the bindings computed by each 
particular solver are properly propagated to the rest of the goal. In particular, 
whenever a variable binding {X \— * t} arises in one of the stores during goal solv- 
ing, the propagation of this binding to the goal applies the binding everywhere, but 
places it only within the substitution of this particular store, so that the first item 
above is ensured. 

At this point we must introduce some auxiliary notations in order to make 
this idea more precise. Let T> stand for any of the four domains M., 7i, TT> 
or 1Z and consider the store S = Us □ as corresponding to T>. We will note as 
{PUCUMOHUFO R)@ v o' the result of applying o' to PUCnMUHUFUR 
and composing as with a' . More formally, in the particular case that T> is chosen 
as TV, we define (PDCOMOHDFO R)@f V o' as Pa' □ Co' □ M * o' □ H * 
a' □ F@o' OR-ko' , where F@a' is defined as U F o' □ o F o' and S * a' is defined as 
ITser' □ as * a' for S being M, H or R. Recall that the application of a' to as has 
been defined as os*o' — oso' \ vdom(os) in Subsection l2.2[ and note that os*o' 
retains the same domain as as- 

The notations explained in the previous paragraph will be used for presenting 
several goal transformation rules in the next subsections. The formal definition for 
the other three possible choices of V is completely analogous. In the rest of the 
paper, we will restrict our attention to so-called admissible goals G that arise from 
initial goals through the iterated application of goal transformation rules and enjoy 
the goal invariant properties just described. 



3.2 Constrained Lazy Narrowing Rules 

The core of our cooperative goal solving calculus CLNC(C) consists of the goal sol- 
ving rules displayed in Table [3] Roughly speaking, these rules model the behaviour 
of constrained lazy narrowing ignoring domain cooperation and solver invocation. 



They have been adapted from ( Lopez- Fraguas et al. 2004 ) and can be classified 



as follows: The first four rules encode unification transformations similar to those 
found in the 7i sts (see Subsection I2.4.2|) and other related formalisms; rule EL 
discharges unneeded suspensions, rule DF (presented in two cases in order to op- 
timize the k = case) applies program rules to deal with calls to program defined 
functions; rule PC transforms demanded calls to primitive functions into atomic 
constraints that are placed in the pool; and rule FC, working in interplay with PC, 
transforms the atomic constraints in the pool into a flattened form consisting of a 
conjunction of atomic primitive constraints with new existential variables. 

The behaviour of the main rules in Table [3] will be illustrated in Subsection 13.51 
Example [8] below focuses on the transformation rules PC and FC. Their iterated 
application flattens the atomic ^-constraint (RX + 2*RY) *RZ <= 3.5 into a con- 
junction of four atomic primitive 7?.-constraints involving three new existential vari- 
ables, that are placed in the constraint pool. Note that ( |L6pez-Fraguas et al. 2004| ) 
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DC Decomposition 

377. h e^T -> h t^, PnCnMOHUFOR H- D c 377. e m -> t m , PacaMaHDFDR 
CF Conflict Failure 

BU. e ^ t,P D C a M D H D F D R h-cf ■ 

If e is rigid and passive, t £ Vir, e and t have conflicting roots. 

SP Simple Production 

377. s -» t, pncnMnffOFafl rH S p 377'. (pncnMnffnpn R)@ n a' 

If s = X £ lAr, t £ Wr, s'={Xh t} and T7 7 = 77 or else s £ Pat c , t = X e Vir, a' = {X h-> s} and 

77' = 77\{x}. 

IM IMitation 

3X,77. h e^^X, PncaMaHaFaR H- IM 3X^,77. (e m ^X m , P a C a M D H a F a R) a ' 
If h e^" ^ Paic is passive, X £ odvar(G) and <r' — {X /i X m }. 

EL ELimination 

3X,77 e ^ X, POCnMOHOFUR If el 377. P □ C □ M □ □ F □ fl 
If X does not occur in the rest of the goal. 

DF Defined Function 

377. / e^T -► t, PnCnMnffnPnP rh D F / 

3F,77. e„ -> t„, r -> t, P □ C', C □ M □ P □ P □ R 

If / £ DF n , t £ Vir or t £ odvar(G) and P/ : / — > r -4= C' is a fresh variant of a rule in V, with 
Y — var(Rl) new variables. 

377. / e^TTQ -> i, PnCnMnPDPnP H- DP 

3X,F,77. e„ -» t„, r - 

If / £ DF" (k > 0), t ( Vir or t £ od«ar(G) and Pi 
P, with y — var(Rl) and X new variables. 

PC Place Constraint 

377. pe^ -> t, PDCDMDHaFaR rf PC 377. Pa P e^^\t, CaMaHaFnR 
If p £ PP" and t £ lAr or t £ odvar(G). 

FC Flatten Constraint 

377. Pn P e;^!(, CnMnffnPnP ^ F c 

3V m ,77. a m ~ y m , P □ p t„ ->! t, COMOHOFOR 

If p £ PP", some ^ Patc, a m {fn < arc those which are not patterns, Vm arc new variables, 
and p £ re is obtained from p e^" by replacing each which is not a pattern by Vi . 



> X, Xoii^t, P □ C", CnMDPnPnP 
: / tn — * r C is a fresh variant of a rule in 



Table 3. Rules for Constrained Lazy Narrowing 
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and other previous related calculi also include rules that can be used to achieve 
constraint flattening, but the resulting atomic primitive constraints are placed in a 
constraint store. In our present setting, they are kept in the pool in order that the 
domain cooperation rules described in the next subsection can process them. 

Example 8 (Constraint Flattening) 

□ (RX + 2 * RY) * RZ <= 3.5 □□□□ l^ F c 

3RA. (RX + 2* RY) * RZ -> RA □ RA <= 3.5 □□□□ ^ P c 

3RA. a (RX + 2 * RY) * RZ ->l RA, RA <= 3.5 □□□□ l^ F c 

3RB, RA. RX + 2* RY -> RB □ RB * RZ^XRA, RA <= 3.5 □□□□ ^ PC 

3-R-B, RA. □ RX + 2 * RY ->! RB , RB * RZ ->! RA, RA <= 3.5 □□□□ ^ FC 

3-RC, RB, RA. 2*RY -> RC □ RX + RC-+\RB, RB * RZ^.RA, RA <= 3.5 □□□□ ^ PC 

3RC, RB, RA. n 2* RY -tliiC, flX + RC^'.RB, RB * RZ^.RA, RA <= 3.5 □□□□ 

Note that suspensions e — > X can be discharged by rule EL in case that X does 
not occur in the rest of the goal. Otherwise, they must wait until X gets bound 
to a non-variable pattern or becomes obviously demanded, and then they can be 
processed by using either rule DF or rule PC, according to the syntactic form of e. 
Moreover, all the substitutions produced by the transformations bind variables X 
to patterns t, standing for computed values that are shared by all the occurrences 
of t in the current goal. In this way, the goal transformation rules encode a lazy 
narrowing strategy. 



3.3 Domain Cooperation Rules 

This subsection presents the goal transformation rules in CCLNC(C) which take 
care of domain cooperation. The core of the subsection deals with bridges and 
projections. A few more ad hoc cooperation rules are presented at the end of the 
subsection. 

Given a goal G whose pool C includes an atomic primitive constraint 7r G 
APCon^T) and whose mediatorial store M includes a set of bridges Bm, we will 
consider three possible goal transformations intended to convey useful information 
from 7r to the 7?.-solver: 

• To compute new bridges bridges^^ 11 (it , Bm) to add to M, by means of a 
bridge generation operation bridges^^^ defined to this purpose. 

• To compute projected "^.-constraints proj :FT '^ n (7T, Bm) to be added to R, by 
means of a projection operation proj^^^ defined to this purpose. 

• To place it into the TV store F. 

Similar goal transformations based on two operations bridges 11 ^^ and proj^^^ 
can be used to convey useful information from a primitive atomic constraint 7r 6 
PCon-ji to the ^"P-solver. Rules SB, PP and SC in Table [4] formalize these trans- 
formations, while tables [5] and [6] give an effective specification of the bridge gener- 
ation and projection operations. 
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SB Set Bridges 

3U.P Ott, COMOHOFOR Vr su 3V' ,U. P □ tt, COM'aHOFOR 

If tt is a primitive atomic constraint and cither (i) or (ii) holds, where 

(i) tt is a proper FZ>-constraint or else an extended "H-constraint such that Af h 7r in TT> , and M ' — B' , Af , 

where 3V 7 B' = bridges^ (tt , B M ) # 0- 
(ii) tt is a proper ^-constraint or else an extended 'H-constraint such that Af h tt in 1Z, and Af — B , Af , 
where 3"V" B' = bridges 11 ^ ^ (tt , B M ) ^ 0- 

PP Propagate Projections 

BU. p n tt, CnMOHOFOR w- PP bv 7 , 77. p □ tt, Comohof'or' 

If tt is a primitive atomic constraint and either (i) or (ii) holds, where 

(i) tt is a proper FZ>-constraint or else an extended H-constraint such that Af h tt in JFZ>, 3V II' — 

proj^ I3 ^' K (7r,B flf ) # 0, F' = f, and ll' = W,R, or else, 
(ii) tt is a proper ^-constraint or else an extended ^-constraint such that M h tt in 1Z : 3V II' — 
proj' R ^ FT \tt : B m ) # 0, F' = n',F, and i?,' = R. 

SC Submit Constraints 

BU. P a tt, CnMnHnFuR rH sc 3F. P □ C □ A/' □ H' O F' □ ij' 

If tt is a primitive atomic constraint and one of the following cases applies: 
(i) tt is a ^-constraint, M' = tt, Af, H' = H, F' = F, and i?,' = _R. 

(ii) 7r is an extended "H-constraint such that neither A-f h 7r in FX> nor Af h 7r in TZ, Af ' — Af , ff ' — tt, H, 
F' = F, and R' = R. 

(iii) tt is a proper FD-constraint or else an extended ^-constraint such that Af h tt in FZ>, Af' — Af , 
H' = H, F' = tt, F, and R' = R. 

(iv) tt is a proper 'R.-constraint or else an extended ?f-constraint such that Af h tt in TZ, Af ' — Af , ff — ff , 
F' = F, and fi' = tt, R. 



Table 4. Rules for Bridges and Projections 

The formulation of SB, PP and SC in Table 2] relies on the identification of 
certain atomic primitive Herbrand constraints tt as JFD-specific or 7\L-specific, as 
indicated by the notations M h tt in TV and M h 7r in 7\L, previously explained 
in Subsection 12.61 The notation II, 5 is used at several places to indicate the new 
store obtained by adding the set of constraints II to the constraints within store S. 
The notation 7r, S (where tt is a single constraint) must be understood similarly. In 
practice, SB, PP and SC are best applied in this order. Note that PP places the 
projected constraints in their corresponding stores, while constraints in the pool 
that are not useful anymore for computing additional bridges or projections will be 
eventually placed into their stores by means of transformation SC. 

The functions bridges D ^ v and proj v ^ v are specified in Table [5] for the case 
V = TV, V = K and in Table M for the case V = K, V = TV. Note that 
the primitive #/ is not considered in Table [5] because integer division constraints 
cannot be projected into real division constraints. The notations \a~\ (resp. [ a J) 
used in Table [6] stand for the least integer upper bound (resp. the greatest integer 
lower bound) of a £ M. Constraints t\ > t 2 , t\ >= t 2 are not explicitly considered 
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in Table [6J they are treated as to, < t\, t<z <= t\, respectively. In tables [5] and [6l 
the existential quantification of the new variables V is left implicit, and results 
displayed as an empty set of constraints must be read as an empty (and thus 
trivially true) conjunction. 


TV 


bridges™^™ (7r,B) 


prof^(n,B) 


domain [-i^i j X 


] a b {Xi #== RXi \ 1 < i < n, Xi has 
no bridge in B and RXi new} 


{ Q <= iJJJQ, RXi <= b 1 l<i<n 
and {Xi #== RXi) e B} 


belongs X [a±, . . . , 


a n ] {X #== R.X X has no bridge in 
B and RX new} 


{roin(ai, . . . , a n ) <= RX, RX <= 
max{a\ , . . . , a n ) | 1 < i < n and 
(X #== RX) £ B} 


tl #< t- 2 

(rcsp. #<=, #>, #=>) 


{X z #== RXi | 1 < i < 2, U is a 
variable with no bridge in 5, 
and R,Xj_ new} 


{tf < tf | For 1 < i < 2: Either 
ti is an integer constant n and t i 
is the integral real n. or else ti is a 
variable Xi with (X; #== fl.X t ) G 
B, and if is iJXi} 


tl == t- 2 


{X #== 7?X | cither t\ is an inte- 
ger constant and tg is a variable 
X with no bridges in B (or vice 
versa) and RX is new} 


{tf == if | For 1 < i < 2: tf is 
determined as in the #< case} 


tl /= t-2 


{X #== 7?X | cither ti is an inte- 
ger constant and ti is a variable 
X with no bridges in B (or vice 
versa) and RX is new} 


{tf /= | For 1 < i < 2: tf is 
determined as in the #< case} 


ii #+ t 2 ->! t 3 
(rcsp. #-, #*) 


{X; #== RXi | 1 < i < 3, tj is a 
variable Xi with no bridge in B 
and new} 


{tf + tf ->! tf | For 1 < i < 3: 
tf is determined as in the #< case} 



Table 5. Computing Bridges and Projections from TV to TL 

The next result states some basic properties of bridges D ^ T> and proj T> ~ >v . The 
easy proof is omitted. 

Proposition 1 (Properties of Bridges and Projections between TV and Tt) 
Let V and V be chosen as TV and TL, or vice versa. Then: 

1. bridges ^ (tt , B) and proj T '^ T> (tt, B) make sense for any atomic primitive 
constraint tt which is either P-proper or extended Herbrand and 2?-specific, 
and for any finite set B of bridges. 

2. bridges ^'' (tt,B) returns a possibly empty finite set B' of new bridges in- 
volving new variables V. In particular, bridges ^' (tt, B) — is assumed 



On the Cooperation of the Constraint Domains TL, 1Z and TT> in CFLP 49 



whenever Tables [5] and [6] do not include any row covering w. The complete- 
ness condition WTSoI c {tt A B) C WTSoI c (3V t {tt ABA B')) holds, where B 
and B' are interpreted as conjunctions. Note that the correctness condition 
Sol c (n AB)D SoleiBV 7 ^ A B A B')) also holds trivially. 
3. proj D ^ T> (ir, B) returns a finite set II' C APCon-p' of atomic primitive V- 
constraints involving new variables V . In particular, proj v ^ v (ir,B) = is 
assumed whenever Tables [5] and [5] do not include any row covering it. The 
completeness condition WTSol c {ir A B) C WTSoI c (3V t (tt ABA II')) holds, 
where B and II' are interpreted as conjunctions. Note that the correctness 
condition Solc(n A B) D Sol c (1V'{ir ABA II')) also holds trivially. 



7T 




bridges 71 ^ 


FT) | 


>,-B) 


proj 




RX < RY 





(no bridges 


are 


created) 


{X #<Y \ {X #== 


RX),(y #== Ry) e s} 


RX < a 





(no bridges 


are 


created) 


{X #< fa] | a e I 


t, (X #== RX) e B} 


a < RY 





(no bridges 


are 


created) 


{ |aj #< Y | a G I 


t, (Y #== RY) £ B] 


RX <= RY 





(no bridges 


are 


created) 


{X #<= y|(X #== 


RX),(Y #== RY) £ B} 


RX <= a 





(no bridges 


are 


created) 


{X #<= L a J 1 a 6 


R, (X #== RX) e B} 


a <= RY 





(no bridges 


are 


created) 


{[a] #<= V | a e 


r, (y #= Ry) e b} 



ti == t 2 {X #== RX | cither £1 is an in- {if = if 15 | For 1 < i < 2: Either * 4 

tegral real constant and £2 is a is an integral real constant n and tf 13 is 

variable RX with no bridges in the integer n, or else £^ is a variable RXi 

B (or vice versa) and X is new} with (Xi #== RXi) G -B, and if 13 is Xi} 



ti /= t 2 (no bridges are created) {tf 73 /= tf For 1 < i < 2: Either ti 

is an integral real constant n and tf 17 is 
the integer n, or else is a variable RXi 
with (Xi #== RXi) e B, and if is Xi} 



{X #== RX I i 3 is a variable RX {if 13 #+ ij ->! if For 1 < i < 3: if 
with no bridge in B, X new, for is determined as in the previous case} 
1 < i < 2, ti is cither an integral 
real constant or a variable RXi 
with bridge (Xi #== RXj) G B} 



ii / t 2 — >! t 3 (no bridges are created) {if 753 #* if D — >! if 15 | For 1 < i < 3 is 

determined as in the previous case} 



tl + t 2 ->! t 3 
(rcsp. -, *) 



Table 6. Computing Bridges and Projections from 1Z to TT> 

Example [9] below illustrates the operation of the goal transformation rules from 
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Table [4] for computing bridges and projections with the help of the functions speci- 
fied in Tables [5] and [6l 

Example 9 ( Computation of Bridges and Projections) 



3RC, RB, RA. □ 2 * RY ->! RC , RX + RC ->! RB , RB * RZ ->! RA , RA <= 3.5 □ 

X #== RX, Y #== RY, Z #== RZ □□□ ^ SB 3 
3C, B, A, RC, RB, RA. □ 2 * RY ->! RC , RX + RC ->! RB , RB * RZ ->! RA , RA <= 3.5 □ 

C #== RC, B #== RB, .4 #== RA, X #== fiX, Y #== RY, Z #== RZ □□□ ^ pp4 
3C, B, A, RC, RB, RA. □ 2 * RY ->! RC , RX + RC ->! RB , RB * RZ ->! RA , RA <= 3.5 □ 

C #== RC, B #== RB, .4 #== RA, X #== RX, Y #== RY, Z #== RZ □□ 

2 #* y ->! C, X #+ C ->! B, B #* Z -»! A, A #<= 3 □ ^ sc 4 
3C, B, A, RC, RB, RA. □□ C #== RC, B #== RB, A #== RA, X #== RX, Y #== RY", Z #== RZ □□ 

2 #* Y -»! C, X #+ C -►! B, B #* Z ->! A, A #<= 3 □ 

2 * RY -►! RC, RX + RC ->! RB, RB * RZ -►! RA, RA <= 3.5 

Note that the initial goal in this current example is an extension of the initial goal 
in Example [5) The first six steps of the current computation are similar to those in 
Example taking care of flattening the ^-constraint (RX+2*RY)*RZ <= 3.5. The 
subsequent steps use the transformation rules from Tabled] until no further bridges 
and projections can be computed and no constraints remain in the constraint pool. 

We have borrowed the projection idea from Hofstcdt's work, see e.g. (Hofstedt 20011 



Hofstedt and Pepper 2007[ ), but our proposal of using bridges to compute projec- 
tions is a novelty. In Hofstedt's approach, projecting constraints from one domain 
into another depends on common variables present in both stores. In our approach, 
well-typing requirements generally prevent one and the same variable to occur 
in constraints from different domains. In order to improve the opportunities for 
computing projections, our cooperative goal solving calculus CCLNC(C) provides 
the goal transformation rule SB for creating new bridges during the computa- 
tions. Some other differences between CCLNC(C) and the cooperative computation 
model proposed by Hofstedt et al. are as follows: 

• All the projections presented in this paper return just one 3 VII'. In Hofs- 
tedt's terminology, such projections are called weak, while projections re- 
turning disjunctions Vfe=i 3VfcH' fe with / > 1 are called strong. The use 
of strong projections is illustrated in ( Hofstedt and Pepper 2007] ) by means 



of a problem dealing with the computation of resistors that have a cer- 
tain capacity. The strong projection used in this example is a finite dis- 
junction of conjunctions of the form X —= x A Y == y for various nu- 
meric values x and y. Solving this disjunction gives rise to an enumeration 
of solutions. In (jEstcvcz-Martf n~et al. 2007}) we have presented a solution of 
the resistors problem where an equivalent enumeration of solutions can be 
computed by the ^P-solver via backtracking, without building any strong 
projection. This is possible in our framework due to the presence of label- 
ing constraints, that are not used in the resistor example as presented in 
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(Hofstedt and Pepper 2007). Therefore, strong projections are not necessary 
for this particular example of cooperation between TV and TZ. Theoretically, 
strong projections could be useful in other problems, and rule PP in our 
CCLNC(C) calculus could be very straightforwardly adapted to work with 
strong projections. However, we decided not to do so because we are not 
aware of any useful extension to extend tables [5] and [6] for computing strong 
projections. We could find no formulation of practical procedures for comput- 
ing projections in (Hofstedt and Pepper 2007) and related works, where all 
projections used in examples are presented in an ad hoc manner. 
Currently, our CCLNC(C) calculus projects TV (resp. TZ) constraints from 
the pool C into the 1Z store R (resp. TV store F). Hofstedt's proposal also 
allows to compute projections from constraints placed into the stores. In 
our previous paper (jEstevez-Martm et al. 2007|) . we have sketched a coop- 
erative goal solving calculus where an arbitrary coordination domain was as- 
sumed and projections could act over the constraints within constraint stores. 
In fact, the resistor problem mentioned in the previous item was solved in 
(jEstevez-M artm et al. 2007) by making essential use of projections that acted 
over constraints within the TV and TZ stores. In the current paper, goal solv- 
ing is restricted to the coordination domain C = M ® TL ® TV TZ and 
projections can be applied only to the constraints placed in the constraint 
pool. These two limitations correspond to the state of the current TOy im- 
plementation. In particular, projections acting over stored constraints are not 
yet handled because the current TOy system has no convenient mechanisms 
for processing the constraint stores handled by the underlying SICStus Prolog. 
Goal solving in CCLNC{C) enjoys the soundness and completeness properties 
presented in Subsection 13. 61 In our opinion, these are more elaborate than the 
soundness and completeness results provided in Hofstedt's work. 



IE Infer Equalities 

3(7. Pnc □ X #== RX, X' #== RX, M □ H □ FOR ^ UB 

377. P o C □ X #== RX, M □ H □ X == X', FDR. 

377. Pnc □ X #== RX, X #== RX', M □ H □ FOR ^ UB 

377. P □ C □ X #== RX, M D H □ FnRX=RX',R. 

ID Infer Disequalities 

377. Pnc □ X*/=u', M □ H □ FOR H- ID 377. P □ C □ M □ H □ X/=u,FDR 
if u £ Z, u £ M. and u #== u — > true. 

377. Pnc □ u#/==RX, M oho FOR H- ID 377. POCOMOHOFO RX/=u', R 
if u £ Z, u' G R and u #== u' — > true. 



Table 7. Rules for Inferring 7i-constraints from .M-constraints 

To finish this subsection, we present the goal transformation rules in Table [71 
which can be used to infer H-constraints from the .M-constraints placed in the store 
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M. The inferred W-constraints happen to be JFP-specific or "/^.-specific, according to 
the case, and can be placed in the corresponding store. Therefore, the rules in this 
group model domain cooperation mechanisms other than bridges and projections. 

3-4 Constraint Solving Rules 

The presentation of CCLNC(C) finishes with the constraint solving rules displayed 
in Table [H Rule SF models the detection of failure by a solver, and the other rules 
describe the possible transformation of a goal by a solver's invocation. Each time a 
new constraint from the pool is placed into its store by means of transformation SC, 
it is pragmatically convenient to invoke the corresponding solver by means of the 
rules in this table. The solvers for the four domains A4, H, TV and 1Z involved in the 
coordination domain C are considered. The availability of the .M-solver means that 
solving mediatorial constraints contributes to the cooperative goal solving process, 
in addition to the role of bridges for guiding projections. 



MS A4-Constraint Solver (glass-box) 

3U. P □ C □ M □ H □ P □ R Vr MS BY 7 ,!/. (P □ C □ (n' □ a M ) D H □ F □ R)@ M a' 
If pvar(P) n var(Yl M ) = 0, (Hm □ a M ) is not solved, n M Vt~ solvli M 3Y T (n' □ a'). 

HS H-Constraint Solver (glass-box) 

3D. P □ C □ M □ H □ F □ R ^hs aF 7 ,!/. (P □ C □ M □ (n' □ an) □ F □ R)@ n a' 
If pvar(P) D odvarti(TlH ) — 0, X —def pvar(P) D var(Hn ), (JIh □ <tk) is not x-solved, 

A- 

FS .PP-Constraint Solver (black-box) 

3D. P □ C □ M □ ff □ P □ R fr FS aY 7 ,!/. (P □ C □ AT □ H □ (n' □ <T F ) □ R)@f-d<t' 
If pvar(P) n t>ar(nir) = 0, (IIf □ a F ) is not solved, IIf H- bo i vc FT> 3Y T (Il' □ <x'). 

R.S P-Constraint Solver (black-box) 

3D. P □ C □ Af □ H □ P □ R Vms aF 7 ,! 7 . (P □ C □ M □ H □ P □ (n' □ <tr))@ w </ 
If pvar(P) n i>ar(n R ) = 0, (II n □ ctr) is not solved, IIr H- solv<1 TZ 3Y T (II' □ a'). 

SF Solving Failure 

3V. P □ C □ M □ □ P □ P h^sF ■ 

If S is the P-storc (P being X, W, JFP or K), pvar(P) nodvar-o (n" s ) = 0, A" = de/ pvar(P) n war (lis ), 
(lis n (Ts) is not x-solved and lis H- . x> ■. Note that X ^ is possible only in the case P — 7i. 

solve v 



Table 8. Rules for A4, Tt, TV and 1Z Constraint Solving 

Let V be any of the four domains, and let II be the set of constraints included in 
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the V store in a given goal G with productions P. As explained in Subsection l2.4.1[ 
each invocation solve (IT, X) depends on a set of critical variables X C cvar-p (IF) 
which must be properly chosen. On the other hand, the goal invariants explained in 
Subsection 13.11 require that no produced variable is bound to a non- linear pattern, 
and the safe binding condition satisfied by any solver ensures that a solver invocation 
never binds any variable X 6 X, except to a constant. 

Because of these reasons, the rules in Table|8]allow a solver invocation solve® (II, X) 
only if the following two conditions are satisfied: 

(a) pvar(P) n odvar^QT) = 0- 

Motivation: If this condition does not hold, for any choice of X C cvarj) (II) 
there is some variable X G pvar(P) \ X, and the solver invocation could bind 
X to a non-linear pattern. 

(b) X = pvar(P) n var (IT). 

Motivation: Because of condition (a), this X is a subset of cvarx)(lF), and the 
safe binding condition of solvers ensures that the invocation solve v (Il, X) will 
bind no produced variable, except to a constant. 

When T> is not 7i, we know from Section [2] that all the variables in n can be 
assumed to be obviously demanded. Then odvar-p (II) = var (II), condition (a) be- 
comes pvar(P) fl var(lF) = 0, (b) becomes X = 0, and solve v (H, 0) can be ab- 
breviated as solve (IF). The rules related to M, TT) and TZ in Table [8] assume 
the simplified form of condition (a), (b). The notations n ti- so i ve p BY' (IF Da') 
and IT W~ so x Vf p M introduced in Subsection 12.4.11 are used to indicate the non- 
deterministic choice of an alternative returned by a successful D-solver invocation 
and a failed P-solver invocation, respectively. Note also the use of the notation 
(. . .)@x>cr' explained near the end of Subsection 13. II 

At this point, we can precise the notion of solved goal as follows: a goal G is 
solved iff it has the form BU-UUMOHUFUR (with empty P and C) 
and the CLA r C(C)-transformations in Tables [7] and [8] cannot be applied to G. The 
CLNC(C ^transformations in Tables [3] and |4] are obviously not applicable to solved 
goals, since they refer to P and C. 

3.5 One Example of Cooperative Goal Solving 

In order to illustrate the overall behavior of our cooperative goal solving calculus, we 
present a CCLNC(C) computation solving the goal Goal 2 discussed in Subsection 
11.21 The reader is referred to Figure for a graphical representation of the problem 
and to Subsection 13.11 for a formulation of the goal and the expected solution in 
the particular case d = 2, n = 4. However, the solution is the same for any choice 
of positive integer values d and n such that n = 2*d, and here we will discuss the 
general case. 

The CCLNC(C) calculus leaves ample room for choosing a particular goal trans- 
formation at each step, so that many different computations are possible in prin- 
ciple. However, the TOy implementation follows a particular strategy. The part 
P □ C of the current goal is treated as a sequence and processed from left to right, 
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with the only exception of suspensions e — > X that are delayed until they can be 
safely eliminated by means of rule EL or the goal is so transformed that they cease 
to be suspensions. As long as the current goal is not in solved form, a subgoal is 
selected and processing according to a strategy which can be roughly described as 
follows: 

1. If P includes some production which can be handled by the constrained lazy 
narrowing rules in Table [3] the leftmost such production is selected and pro- 
cessed. Note that the selected production must be either a suspension e — > X 
that can be discharged by rule EL, or else a production that is not a sus- 
pension. The applications of rule DF are performed in an optimized way by 
using definitional trees (jdel Vado-Virseda 20051 [del Vado-Virseda 2007|) . 

2. If P is empty or consists only of productions e — -> X that cannot be processed 
by means of the constrained lazy narrowing rules in Table [3l and moreover 
some of the stores M, H , F or R is not in solved form and its constraints 
include no produced variables, then the solvers for such stores are invoked, 
choosing the set X of critical variables as explained in Table [H 

3. If neither of the two previous items applies and C is not empty, the leftmost 
atomic constraint S in C is selected. In case it is not primitive, the flattening 
rule FC from Table[3]is applied. Otherwise, S is a primitive atomic constraint 
tt, and exactly one of the following cases applies: 

(a) If 7r is a proper ^P-constraint or else an extended 7Y-constraint such 
that M h 7r in TV, then tt is processed by means of the rules SB, PP 
and SC from Table [4j This generates bridges and projected constraints 
7t', if possible, and submits tt to the store F. Then, the rules from Table 
[8] are used for invoking the JT^-solver (in case that the constraints in 
F include no produced variables) and the 7tL-solver (in case that the 
constraints in R include no produced variables). 

(b) If tt is a proper ^-constraint or else an extended 7i-constraint such that 
M h tt in 1Z, then tt is processed by means of the rules SB, PP and 
SC from Tabled] This generates bridges and projected constraints tt' , if 
possible, and submits tt to the store R. Then, the rules from Table [8] are 
used for invoking the 7^-solver (in case that the constraints in R include 
no produced variables) and the .T-T'-solver (in case that the constraints 
in F include no produced variables). 

(c) If tt is an extended 7i-constraint such that neither M h tt in TV nor 
M h tt in TZ, then tt is submitted to the store H by means of rule SC, 
and the 7i-solver is invoked in case that the constraints in H include no 
obviously demanded produced variables. 

(d) If tt is a A^-constraint, then tt is submitted to the store M by means of 
rule SC, the rules of Table[7]are applied if possible, and the A'l-solver is 
invoked in case that the constraints in M include no produced variables. 

The series of goals Go up to G\i displayed below correspond to the initial goal, 
the final solved goal and a selection of intermediate goals in a computation which 
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roughly models the strategy of the TOy implementation, working with the pro- 
jection functionality activated. In the initial goal, d and n are arbitrary positive 
integers such that n = 2*d and d' = d+0.5. 

Go : □ bothln (triangle {d,d') 21) (square n) (X, Y) == true □□□□ ^ FC 

Gi : 3UT. bothln (triangle (d, d') 2 1) (square n) (X, Y) — > A □ A== true □□□□ H- Sc(11 ) 

G 2 : 3U2- bothln (triangle (d, d') 2 1) (square n) (X, Y) — > A □ □□ A == trueDD ^DF tot . 7n 

G 3 : JUl.triangle (d, d') 2 1 — > A, sgnare n -> G , (X, y) -» (X', 1"), true -> A □ 

X' #== AX, y' #== fly, isInR(RX, RY) == true, is/n G (X', V) == true, 
iabeiing [] [X',y'J □□ A == true □□ ^ p2 DC Sp3 HS 

Gi : SUI. D X #== RX , Y #== Ay , is/ra (triangle (d, d') 2 1) (AX, fly) == true, 

isln (square n) (X. Y) — true, labeling [] [X . Y] □□ cr.tr □□ H-* 2 Mg 

Gs : 3U$. □ isln (triangle (d, d ) 21) (RX, RY)—— true, isln (square n) (X,Y) — — true, 
labeling {] [X,Y] OX #== RX , Y #== flya o- H □□ H-J, LN 

G 6 : STTe". □ RY >= d' - 1 , 2* fly - 2*1* AX <= 2 * d' - 2 * 1 * d, 

2* fly + 2*1* flX <= 2 * d' + 2 * 1 * d, domain [X, F]On, 
labeling [] [X, V] □ X #== AX, V #== RYU a' H □□ H-p c pc 

G7 : 3(77. □ d' - 1 — >!AA , fly >= flA, 2 * fly - 2 * 1 * flX <= 2 * d! - 2 * 1 * d, 
2* fly + 2*1* flX <= 2 * d' + 2 * 1 * d, domain [X, Y]0n, 
labeling [] [X,Y] □ X #== flX, Y #== fl.ya tr^ □□ Ifgorivi.RS 

G s : aUg. □ fly >= d" , 2 * fly -2*1* ax <= 2 * d' - 2 * 1 * d, 

2* Ay + 2*1* AX <= 2 * d' + 2 * 1 * d, domain [X, y] n, 
labeling [] [X,Y] □ X #= AX, y #== RYU a' H □□ S R H-g P cs 

G 9 : 3£7g. □ 2* Ay - 2*1* AX <= 2 * d' - 2 * 1 * d , 

2 * Ay + 2*1* AX <= 2*d' + 2*l*d , domain [X, y] n, labeling [] [X, y] □ 

x #== rx, y #== fly □ ct^j □ y# >= d □ fly >= d", s R n- FR BP 

Gio : 3C7io. □ domain [X, y] n, labeling [ ] [X, V] □ 

x #== flx, y #== fly b #== rb, c #= AC, s"„, □ </„ □ 



y# > = rf, 2# * y# - 2# * X ->!B, fl# < = 1, 2# * y# + 2# * X ->!C, c# <= s f □ 
Ay >= d", 2 * Ay - 2 * AX ->!flB, AS <= 1, 2 * Ay + 2 * AX -*\RC, AC <= n' , S' R H-J, s 

Gn : 3Un. □ domain [d, d\ n, labeling [] [d, d] □ □ er^ □ S F □ S R H~sc(iii) FS SC(iii) FS 

G12 : 3C/i2. □ □ S'm a a' H □ Sp □ S« 



The local existential variables 3Z7j of each goal Gi are not explicitly displayed, 
and the notation G,_i Gi is used to indicate the transformation of Gj_i into 

Gi using the goal solving rules indicated by 1ZS. At some steps, 1ZS indicates a 
particular sequence of individual rules, named as explained in the previous subsec- 
tions. In other cases, namely for i = 6 and 9 < i < 11, 1ZS indicates sets of goal 
transformation rules, named according to the following conventions: 

• CLN names the set of constrained lazy narrowing rules presented in Table [3] 

• FR names the set consisting of the two rules FC and PC displayed at the 
end of Table [31 used for constraint flattening. 

• BP names the set of rules for bridges and projections presented in Table |U 

• CS names the set of constraint solving rules presented in Table [H 

We finish with some comments on the computation steps: 

• Transition from Go to G\\ The only constraint in G is flattened, giving rise 
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to one suspension and one flat constraint in the new goal. The produced 
variable A is not obviously demanded because the constraint A == true is 
not yet placed in the 7i-store. 

Transition from G\ to G2' The only suspension is delayed, and the only con- 
straint in the pool is processed by submitting it to the 7i-store. However, the 
7i-solver cannot be invoked at this point, because A has become an obviously 
demanded variable that is also produced. 

Transition from G2 to G3: The former suspension has become a production 
which is processed by applying the program rule defining the function bothln, 
which introduces new productions in P and new constraints in C. 
Transition from G3 to G4: The four productions in P are processed by binding 
propagations and decompositions (rules SP and DC), until P becomes empty. 
Then the 7i-solver can be invoked. At this point, the 7i-store just contains a 
substitution an resulting from the previous binding steps. 
Transition from G4 to G5: P is empty, and the two first constraints in G are 
bridges. They are submitted to the .M-store and the .M-solver is invoked, 
which has no effect in this case. 

Transition from G5 to Gq: There are no productions, and the two first con- 
straints in the pool are processed by steps similar to those used in the tran- 
sition going from Go to G4. Upon completing this process, the new pool in- 
cludes a number of new constraints coming from the conditions in the program 
rules defining the functions isln, triangle and square, and the substitution 
stored in H has changed. At this point, P is empty again and the constraints 
in G plus the bridges in M amount to a system equivalent to the one used in 
Subsection 11.21 for an informal discussion of the resolution of Goal 2. 
Transition from G§ to G7 and from G7 to G$: There are no productions, 
and flattening the first constraint in G gives rise to the primitive constraint 
d'-l — ►! RA. This is submitted to the 7?.-store and the 7£-solver is invoked, 
which computes d ' ' as the numeric value of d ' -1 and propagates the variable 
binding RA t— > d' ' to the whole goal, possibly causing some other internal 
changes in the IZ-store. 

Transition from Gs to Gg: There are no productions, and the first constraint 
in G is now RY >= d". Since d" = d'-l = d+0.5-1 = d-0.5, we have 
|~d' '] = d. Therefore, projecting RY >= d' ' with the help of the available 
bridges (including Y #== RY) allows to compute Y #>= d as a projected TT>- 
constraint. Both RY >= d' ' and Y #>= d are submitted to their respective 
stores and the two solvers are invoked, having no effect in this case. 
Transition from Gg to G%o: There are no productions, and the two first atomic 
constraints in the pool of Gg (two ^-constraints <5i and 62) are processed by 
steps similar to those used in the transition going from G§ to Gg , except that 
the solver invocations are delayed to the transition from G10 to Gn and com- 
mented in the next item. (Actually, the TOy implementation would invoke 
the solvers two times: The first time when processing Si and the second time 
when processing 62- Here we explain the overall effect of the two invocations 
for the sake of simplicity.) Upon completing this process, G10 stays as fol- 
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lows: P is empty, C includes the two other constraints which were there in 
Gg, and the stores M, F and R have changed because of new bridges and 
projections. In fact, the constraints within the stores F and R in G±q would 
be equivalent but not identical to the ones shown in this presentation, due to 
intermediate flattening steps that we have not shown explicitly. In particular, 
the ^-constraint 2*RY-2*RX ->■! RB and its JRD-projection 2#*Y#-2#*X ->! 
B would really not occur in this form, but a conjunctions of primitive con- 
straints obtained by flattening them would occur at their place. 

• Transition from Gio to G\\: At this point, the JT^-solver is able to infer that 
the constraints in the TT> store imply one single solution for the variables X 
and Y, namely {X d, Y i— > d}. Therefore, the .T-T'-solver propagates these 
bindings to the whole goal, affecting in particular to the bridges in M . Then, 
the A^-solver propagates the corresponding bindings {RX ^ rd, RY h rd}. 
(rd being the representation of d as an integral real number), and the 7^-solver 
succeeds. 

• Transition from G\\ to G\2'- The two constraints in C have now become 
trivial. Submitting them to their stores and invoking the respective solvers 
leads to a solved goal, whose restriction to the variables in the initial goal 
is the computed answer □□□□ (0 □ {X i-> d, Y h d}) D. Note that no 
labeling whatsoever has been performed, independently of the size of n. 

3. 6 Properties of the Cooperative Goal Solving Calculus CCLNC(C) 

This final subsection presents the main semantic results of the paper, namely sound- 
ness and limited completeness of the cooperative goal solving calculus CCLNC(C) 
w.r.t. the declarative semantics of CFLP(C) given in ( Lopez- Fraguas et al. 2007). 
To start with, we define the notion of solution for a given goal. 

Definition 10 (Solutions of Goals and their Witnesses) 

1. Let G = 3U. P □ C □ M □ H □ F □ R be an admissible goal for a given 
CFI/-P(C)-program P. The set of solutions Sol-p(G) of G w.r.t. V includes 
all those [i G Vale such that there is some //' G Vale verifying fi' t 1 
and fi' G Sol v (PUCU MUHUFUR), which holds iff the following two 
conditions are satisfied: 

(a) fi' G Sol-p(P □ C). By definition, this means V \~crwl{C) (P a C)//, 
which is equivalent to V \-crwl{c) Prf and V ^crwl(c) Ca' . 
This notation refers to the existence of proofs in the instance 
CRWL(C) of the Constrained Rewriting Logic CRWL, whose in- 
ference rules can be found in ( |L6pez-Fraguas et al. 2007[ ). 

(b) u> G Sol c {M UHUFaR), which is equivalent to a' G Sol c {M) n 
Solc(H) n Solc(F) n Solc(R). 

2. If Ai is a multiset having as its members the Ci?W / L(C)-proofs mentioned in 
item l.(a) above, we will say that Ai is a witness for the fact that /i G Sol-p(G), 
and we will write M : fi G Sol-p(G). 
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3. A solution /i G Sol-p{G) is called well-typed iff the valuation // =\yj /i men- 
tioned in item 1. can be so chosen that (PUCUMUHUFU R)^' is well- 
typed, which is noted as n' G WTSol v (P '□ C '□ M □ i? □ F '□ R). The set 
of all well-typed solutions of G w.r.t. V is written as WTSol-p(G). In case 
that M. is a witness for p G Sol-p(G), we also say that A'f is a witness for 
(jl G WTSWp(G) and we write WTSoZp(G). 

In case that G is a solved goal S, we write Solc{S) (resp. WT'SoZc(S')) in place 
of Sol v (S) (resp. WTSol r (S)). 

Concerning item l.(b) in the previous definition, note that the equivalence n G 

Sok(M) n Solc(H) n SoZcC-F) n 5o/ c (-R) Sol M {M) n Sol H {H) n Sol r {F) n 

Sol-jz(R) does not make sense in general, because a given valuation 77 G Fa^c is 
not always a £> valuation when X> is chosen as one of the four components of C. 
However, Theorem [2] from Subsection 12.51 allows to reason with solutions known 
for C in terms of solutions known for the four components, as we will see in the 
mathematical proofs of Appendix IA.2I 

Before presenting our soundness and completeness results for CCLNC{C) let us 
comment on some limitations concerning completeness: 

• As already said in Subsection 13.11 the design of CCLNC(C) is tailored to 
programs and goals having no free occurrences of higher-order logic variables. 
Therefore, the completeness results of this subsection are limited to this kind 
of programs and goals. 

• The completeness of CCLNC(C) is obviously conditioned by the completeness 
of the solvers invoked by the goal transformation rules in Tabled] On the other 
hand, the completeness requirement for solvers in Definition [6] is limited to 
well-typed solutions. Therefore, the completeness results of this subsection 
refer only to well-typed solutions of the initial goal. 

• As discussed in Subsections 12.4.21 12.4.31 and 12.4.41 certain invocations of con- 
straint solvers can be incomplete even w.r.t. well-typed solutions. Therefore, 
the completeness results of this subsection are also limited by the assumption 
that no incomplete solver invocations occur during goal solving. 

• Finally, the goal transformation rule DC from Table [3] can give rise to opaque 
decompositions. Similarly to the opaque decompositions caused by the trans- 
formation rules H3 and H7 for H-stores (see Subsection I2.4.2|) , the opaque 
decompositions caused by DC can lose well- typed solutions. In what follows, 
we will say that an application of the goal transformation rule DC is trans- 
parent iff the expression he m involved in the rule application is such that 
h is m-transparent (or equivalently, h is not m-opaque). Only transparent 
applications of the rule DC can be trusted to preserve well-typed solutions. 
For this reason, the completeness results of this subsection are limited by the 
assumption that no opaque applications of rule DC occur during goal solving. 
Unfortunately, the eventual occurrence of opaque decomposition steps during 
goal solving (be they due to rule DC from Table [3] or to the stss H3 and 
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H7 of the 7i-solver) is an undecidable problem, because of theoretical results 
proved in ([Gonzalez-More no et al. 2 001). 

In the sequel we will use the notation G H~rl,7,-p G' to indicate that the ad- 
missible goal G for the C-FLP(C)-program V is transformed into the new goal G' 
by an application of the selected rule RL applied to the selected part 7 of G. It is 
important to note that the selected part 7 of G must have the form expected by 
the selected rule RL. More precisely, 7 must be selected as one of the stores in case 
that RL is some the transformations in Table [U as a pair of bridges in case that RL 
is the transformation IE from Table [3 and as an atom in any other case. We will 
use also the notation G H~ RL 7 v G' to indicate the existence of some computation 
of the form G H^rl,7,p G\ Yr*p G' transforming G in G' in n steps for some n > 1. 

We are now in a position to present the main results of this subsection. First, we 
state a theorem which guarantees local soundness and completeness for the one-step 
transformation of a given goal. A proof is given in Appendix IA.21 

Theorem 4 (Local Soundness and Limited Local Completeness) 
Assume a given program V and an admissible goal G for V which is not in solved 
form. Choose any rule RL applicable to G and select a part 7 of G suitable for 
applying RL. Then there are finitely many possible transformations G H-rl^p G'j 
(1 < j < k), and moreover: 

1. Local Soundness: Sol v (G) D [f ]=1 Sol-piG 1 ^. 

2. Limited Local Completeness: WTSol v (G) C [f. =1 WTSol-p^), pro- 
vided that the application of RL to the selected part 7 of G is safe in the 
following sense: it is neither an opaque application of DC nor an application 
of a rule from Table [5] involving an incomplete solver invocation. 

A global soundness result for CCLNC(C) follows easily from the first item of 
Theorem |4] In particular, it ensures that the solved forms obtained as computed 
answers for an initial goal using the rules of the cooperative goal solving calculus 
are indeed semantically valid answers of G. 

Theorem 5 (Soundness Theorem) 

Assume a CFLP (C)-program V, an admissible goal G for V, and a solved goal S 

such that G Vr* v S. Then, Sol c (S) C Sol v (G). 

Proof 

As an obvious consequence of Theorem |4] (item 1.), one gets Sol-p(G') C Sol-p(G) 
for any G' such that G Yr-p G'. From this, an easy induction shows that Sol-p(S) C 
Sol-p(G) holds for each solved form S such that G H-p S. Since Sol-p(S) = Solc(S), 
the soundness result is proved. □ 

Note that the local completeness part (item 2.) of Theorem |4] also implies that 
failing goals have no solution; i.e., from a failing transformation step G H~rl.p B 
we can conclude WTSol-p(G) — 0, provided that the application of RL is safe. 
However, a global completeness result for CCLNC(C) does not immediately follow 
from item 2. of Theorem |U For an arbitrarily given /1 G WTSol-p(G), completeness 
needs to ensure a terminating CCLNC(C) computation ending up with a solved 
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form S such that fj, G WTSol c {S). According to Definition [101 \i G WTSol P {G) 
implies the existence of a witness Af : /x G WTSol-p{G). In Appendix IA.2I we have 
defined a well-founded progress ordering > between pairs (G, M) formed by a goal 
G and a witness, and we have proved the following result: 

Lemma 6 {Progress Lemma) 

Consider an admissible goal G for a GFLP(C)-program V and a witness At : fj, G 
VFT.S'oZt^G). Assume that neither V nor G have free occurrences of higher-order 
variables, and that G is not in solved form. Then: 

1. There is some RL applicable to G which is not a failing rule. 

2. Assume any choice of a rule RL (not a failure rule) and a part 7 of G, such 
that RL can be applied to 7 in a safe manner. Then there is some finite 
computation G H~r L „ v G' such that: 

• im G WTSoZp(G'). 

• There is a witness At' : pL G WTSoZ^G') verifying (G, At) > (G', At'). 
Using the former lemma, we can prove the following completeness result: 

Theorem 6 {Limited Completeness Theorem) 

Let an admissible goal G for a program V and a well- typed solution /j, G W / T5oZp(G) 
be given. Assume that neither V nor G have free occurrences of higher-order vari- 
ables. Then, unless prevented by some unsafe rule application, one can find a 
GGLiVG(C)-coniputation G W~ v S ending with a goal in solved form S such that 
H e WTSolc{S). 

Proof 

The thesis of the theorem can be rephrased by writing /1 G WTSol-p{S) in place 
of the equivalent condition fi G WTSolc{S). The hypothesis allow us to choose a 
witness At : (1 G WTSol-p{G). In order to prove the rephrased thesis we reason by 
induction on the well-founded ordering > (see e.g. (Baader and Nipkow 1998) for an 
explanation of this proof technique) . In case that G is a solved goal, the rephrased 
thesis holds trivially with 5* taken as G itself. In case that G is not solved, we apply 
the Progress Lemma|6]to V and At : fj, G WTSol-p{G) and we obtain a rule RL and 
a part 7 of G such that RL can be applied to 7. Assuming that this rule application 
is a safe one, Lemma |6] also provides a finite computation G H~r L „ j> G' such that 
there is a witness At' : fi G WTSol v {G') fulfilling (G, At) > (G', At'). Since neither 
V nor G have free occurrences of higher-order variables, the same must be true 
for G'. By well-founded induction hypothesis we can then conclude that, unless 
prevented by some unsafe goal transformation step, one can find a computation 
G' H-p S ending with a goal in solved form S such that fx G WTSol-p{S). The 
desired computation is then G H-^ L p G' H-p 5. □ 

4 Implementation 

This section sketches the implementation of the CCLNC{C) computational model 
on top of the TOy system. The current implementation has evolved from older 
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versions that supported the domains TL and 7Z, but not yet TV and its cooperation 
with TL and 1Z. We describe the architectural components of the current TOy sys- 
tem and we briefly discuss the implementation of the main cooperation mechanisms 
provided by CCLNC(C), namely bridges and projections. The reader is referred to 
([Arenas et al. 20071 lEstevez-Martm et al. 20061 lEstevez-Martm et al. 20071 lEstevez-Martm et al. 2008j) 
for more details. 

Instead of using an abstract machine for running byte-code or intermediate 
code, TOy programs are compiled to and executed in Prolog, as in other re- 
lated systems ( | Antoy and Hanus 2000 ) . The compilation generates Prolog code 



that implements goal solving by constrained lazy narrowing guided by definitional 
trees, a well known device for ensuring an optimal behaviour of lazy narrowing 
dLoogen et al. 1993[ |Antoy et al. 1994[ |Antoy et al. 2000| Idel Vado-Vfrseda 2003| 
Idel Vado-Vrrseda 2005| Idel Vado-Vi'rseda 2007|) . TOy relies on an efficient Pro- 
log system, SICStus Prolog (SICStus Prolog 2007), which provides many libraries, 
including constraint solvers for the domains TV and 1Z. 

TOy is distributed (http : //toy . sourcef orge .net) as a free open-source Source- 
forge project and runs on several platforms. Installation is quite simple. Console 
and windows executables are provided, no further software is required. In addition, 
TOy can be used inside ACIDE (|Saenz-Perez 2007|) . an emerging multiplatform 
and configurable integrated development environment (alpha development status). 



4-1 Architectural Components of the Cooperation Schema 

Fig. |4] shows the architectural components of the cooperation schema in TOy. As 
explained in Subsection 12. 6[ the three pure constraint domains TL, 1Z and TV are 
combined with a mediatorial domain M. to yield the coordination domain C — A4 
TL® TV ®1Z which supports our cooperation model. Therefore, these four domains 
are supported by the implementation. Moreover, the set of primitives supported by 
the domains 1Z and TV in the TOy implementation is wider than the simplified 
description given in subsections 12.4.31 and 12.4.41 
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Fig. 4. Architectural Components of the Cooperation Schema in TOy 



The solvers and constraint stores for the domains TV and 1Z are provided by the 
SICStus Prolog constraint libraries. The impedance mismatch problem among the 
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host language constraint primitives and these solvers is tackled by glue code (see 
Subsection 14. 2 [I . Proper TV— and TZ— constraints, as well as Herbrand constraints 
specific to TV and TZ (see Subsections 12.4.41 and 12. 4l3|) are posted to the respective 
stores and handled by the respective SICStus Prolog solvers. On the other hand, 
the stores and solvers for the domains Tt and M. are built into the code of the 
TOy implementation, rather than being provided by the underlying SICStus Prolog 
system. 

4-2 Implementing Domain Cooperation 

This subsection explains the implementation of the fundamental mechanisms for 
domain cooperation: Bridges and projections. The constraints provided by the me- 
diatorial domain M. and their semantics have been explained in Subsections 12.51 
and 12.61 Mediatorial constraints have the general form a #==b — Ac, with a ::int, 
b :: real and c :: bool, while bridges a #== b and antibridges a #/== b abbreviate a 
#== 6 — A true and a #==b — A false, respectively. 

In order to deal with Ti. and M. constraints, the TOy system uses a so-called 
mixed store which keeps a representation of the 7i and M. stores as one single 
Prolog structure. It includes encodings of 7i-constraints in solved form (i.e., totality 
constraints X == X and disequality constraints X /= t), as well as encodings of 
bridges and antibridges. The implementation of the H and M. solvers in TOy is 
plugged into the Prolog code of various predicates which control the transformation 
of the mixed store (passed as argument) by means of two auxiliary arguments Cin 
and Cout. 

In the next three subsections we discuss the implementation of mediatorial con- 
straints and projections. We will show and comment selected fragments of Prolog 
code, involving various predicates with auxiliary arguments Cin and Cout, as ex- 
plained above. Regarding projections, the TOy implementation has been designed 
to support two modes of use: A 'disabled projections' mode which allows to solve 
mediatorial constraints, but computes no projections; and a 'enabled projections' 
mode which also computes projections. For each particular problem, the user can 
analyze the trade-off between communication flow and performance gain and decide 
the best option to execute a goal in the context of a given program. 

4-.2.1 The Equivalence Primitive #== 

The equivalence primitive #== : : int — > real — > bool used for building media- 
torial constraints is implemented as a Prolog predicate (also named #==) with five 
arguments, whose explanation follows. Arguments L and R stand for the left (in- 
teger) and right (real) parameters of the primitive #==. Argument Out stands for 
its result. Finally, arguments Cin and Cout stand for the state of the mixed store 
before and after performing a call to the primitive #==, respectively. Fig. [5] shows 
the Prolog code for the predicate #==, and the comments below explain why this 
code implements the M. solver described in Table [2] of Subsection 12.61 and the spe- 
cial cooperation rules IE and ID of the CCLNC(C) calculus specified in Table [7| 
from Subsection 13.31 
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Lines (2) and (3) compute the head normal forms (hnfs) of L and R into HL and 
HR, respectively. This process may generate new Herbrand constraints that will be 
added to the mixed store. The value of HL resp. HR will be either a variable or a 
number, ensuring that no suspensions will occur in the Prolog code from line (4) 
on. This code is intended to process the constraint HL #== HR — ►! Out according 
to the behaviour of the .M-solvcr specified in in Table [2 Subsection 12.61 Due to 
rules Ml and M2 in Tabled the constraint is handled as a bridge HL #== HR when 
Out equals true, and as an antibridge HL #/== HR when Out equals false. For this 
reason, one can say that the #== primitive accepts reification. Indeed, in Fig. [5] we 
find that a bridge HL #== HR is posted to the mixed store if the value for Out can 
be unified with true (line (6)), whereas an antibridge HL #/== HR is posted if the 
value for Out can be unified with false (line (10)). 

(1) #==(L, R, Out, Cin, Cout):- 



(2) hnf(L, HL, Cin, Coutl) , 

(3) hnf(R, HR, Coutl, Cout2) , 

(4) tolerance (Epsilon) , 

(5) ( (0ut=true, 

(6) Cout3 = ['#==' (HL.HR) I Cout2] , 

(7) freeze(HL, {HL - Epsilon =< HR, HR =< HL + Epsilon} ), 

(8) freeze (HR, (HL is integer (round (HR) )))) ; 

(9) (0ut=false, 

(10) Cout3 = ['#/==' (HL.HR) I Cout2] , 

(11) freeze(HL, (F is float(HL), {HR =\= F» ) , 

(12) freeze(HR, (0.0 is f loat_f ractional_part (HR) -> 

(13) (I is integer(HR), HL #\= I); true)))), 

(14) cleanBridgeStore(Cout3,Cout) . 



Fig. 5. Implementation of Mediatorial Constraints (#== / 2) 

Solving both bridges and antibridges is accomplished by using the concurrent 
predicate freeze, which suspends the evaluation of its second argument until the 
first one becomes ground. Solving a bridge HL #== HR amounts to impose the 
equivalence of its two arguments (variables or constants), which are of different 
type (integer and real), so that type casting is needed. Variable HL is assigned to 
the integer version of HR (line (8)) via the Prolog functions round and integer, 
implementing rule M3 in Table [2j Similarly, line (7) is roughly intended to assign 
the float version of HL to HR in order to implement rule M5 in Table[2j However, due 
to the imprecise nature of real solvers, occasionally HR's value will be an approxi- 
mation to an integer value. Therefore, line (7) actually constrains the real variable 
HR to take a value between HL - Epsilon and HL + Epsilon, where Epsilon (line 
(4)) is a user-defined parameter (zero by default) which introduces a tolerance and 
avoids undesirable failures due to inexact computations of integer values. Lines (7) 
and (8) also cover the implementation of rule M6 in Table [2] On the other hand, 
solving an antibridge HL #/ == HR amounts to impose that both arguments are not 
equivalent. Therefore, as soon as HL or HR becomes bound to one numeric value, a 
disequality constraint between the (suitably type-casted) value of the bound vari- 
able and its mate argument is posted to the proper SICStus Prolog solver (lines 
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11-13). The code in these lines implements rule M8 in Tableland rule ID in 
Table 

Moreover, the failure rules in Table [2] (namely M4, M7 and M9) are also im- 
plemented by the frozen goals in lines (7) -(8) and (11)-(13) of Fig. Indeed, 
whenever HL and HR become bound, the corresponding frozen goal is triggered and 
the equivalence (resp. non-equivalence) is checked, which may yield to success or 
failure, thus implementing rules M7 and M9; and wherever HR becomes bound to a 
non integral real value, the frozen goal in line (8) yields failure, thus implementing 
rule M4. Finally, line (14)) invokes a predicate that simplifies the mixed store by 
implementing the effect of rule IE in Table [7] applied as much as possible to all the 
available (encodings of) bridges between variables. 

4.2.2 Projection: TV to 72 

If the user has enabled projections with the command /pro j , the TOy system 
can process a given atomic primitive .T-'P-constraint by computing bridges and pro- 
jected ^-constraints as explained in Subsection 13.31 The Prolog implementation 
has a different piece of code (Prolog clause) for each TV primitive which can be 
used to build projectable constraints. The information included in Table [5] for com- 
puting bridges and projections from different kinds of JPD-constraints, as well as 
the effect of the goal transformation rules in Table [H is plugged into these pieces of 
Prolog code. The code excerpt below shows the basic behaviour of the implementa- 
tion for the case of .T-T'-constraints built with the inequality primitive #<, without 
considering optimizations: 
(1) #<(L, R, Out, Cin, Cout):- 



(2) hnf(L, HL, Cin, Coutl) , hnf(R, HR, Coutl, Cout2) , 

(3) ((Out=true, HL #< HR) ; (Out=false, HL #>= HR) ) , 

(4) (proj_active -> 

(5) (searchVarsR(HL, Cout2, Cout3, RHL) , 

(6) searchVarsR(HR, Cout3, Cout , RHR) , 

(7) ((Out==true, { RHL < RHR » ; 

(8) (Out==false, { RHL >= RHR }))); 

(9) Cout=Cout2) . 



Following a technique similar to that explained for #== above, the primitive #< is 
implemented by a Prolog predicate with five arguments (line (1)). Its two input ar- 
guments (L and R) are reduced to hnf (line (2) ), and a primitive constraint is posted 
to the SICStus .FT^-solver, depending on the Boolean result (Out) returned by #< 
(line (3)). Moreover, if projection is active (indicated by the dynamic predicate 
proj_active in line (4)), then, the predicate searchVarsR (lines (5-6)) inspects 
the mixed store looking for bridges relating the TV variable HL and HR to the 72 
variables RHL and RHR, respectively. In case that some of these variables is bound to 
a numeric variable, the relation to the mate variable just means that their numeric 
values are equivalent. Predicate searchVarsR also creates new bridges if necessary, 
according to the specifications in Table and returns the modified state of the 
mixed store in its third argument. Finally, the projected constraints computed as 
specified in Table[5] (in this case, a single constraint, which is either RHL < RHR or 
RHL >= RHR depending on the value of Out) are sent to the SICStus 72-solver. 
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4.2.3 Projection: K to TV 

If the user has enabled projections, the TOy system can also process a given atomic 
primitive ^-constraint by computing bridges and projected ^"P-constraints as ex- 
plained in Subsection 13.31 The Prolog implementation is similar to that discussed 
in the previous subsection, with a different piece of code (Prolog clause) for each 
TZ primitive which can be used to build projectable constraints, and encoding the 
information from Table [6l A comparison between Tables [5] and [6] shows that there 
are less opportunities for building bridges from TZ to TV than the other way round, 
but more opportunities for building projections. The code excerpt below shows the 
basic behaviour of the implementation for the case of ^-constraints built with the 
inequality primitive >, ignoring optimizations: 

(1) >(L, R, Out, Cin, Cout):- 

(2) hnf(L, HL, Cin, Coutl) , hnf(R, HR, Coutl, Cout) , 

(3) (Out = true, {HR > HL} ; Out = false, {HL =< HR}) , 

(4) (proj_active -> 

(5) (searchVarsFDCHL, Cout, BL, FDHL) , 

(6) searchVarsFD(HR, Cout, BR, FDHR) , 

(7) ((BL == true, BR == true, Out == true, FDHL #> FDHR); 

(8) (BL == true, BR == true, Out == false, FDHL #=< FDHR); 

(9) (BL == true, BR == false, Out == true, FDHL #> FDHR); 

(10) (BL == true, BR == false, Out == false, FDHL #=< FDHR); 

(11) (BL == false, BR == true, Out == true, FDHL #> FDHR); 

(12) (BL == false, BR == true, Out == false, FDHL #=< FDHR); 

(13) true); true). 

As in the previous subsection, the primitive > is implemented by a Prolog predi- 
cate with five arguments (line (1)). Its two input arguments (L and R) are reduced 
to hnf (line (2)), and a primitive constraint is posted to the SICStus 7?.-solver, 
depending on the Boolean result (Out) returned by > (line (3)). Moreover, if pro- 
jection is active (line (4)), then predicate searchVarsFD (lines (5-6)) inspects the 
mixed store looking for bridges relating the ^-variables HL and HR to TV- variables. 
As shown in Table [6l no new bridges can be created during this process. Therefore, 
in contrast to the predicate searchVarsR presented in the previous subsection, the 
third argument of predicate searchVarsFD does not represent a modified state of 
the mixed store. Instead, it is a Boolean value that indicates whether a bridge has 
been found or not. More precisely, in line (5) there are two possibilities: Either 
BL is true and HL is a non-bound 7?.-variable related to the .FD-variable FDHL by 
means of some bridge in the mixed store Cout; or else BL is false, HL is bound 
to a real value u, and FDHL is computed as pit]. Analogously, in line (6) there are 
two possibilities: Either BR is true and HR is a non-bound 7?.-variable related to 
the J-"!?- variable FDHR by means of some bridge in the mixed store Cout; or else 
BR is false, HR is bound to a real value it, and FDHR is computed as [u\. Finally, 
lines (7-12) perform a distinction of cases corresponding to all the possiblities for 
projecting the constraint HL > HR — ►! Out according to Table [6] and the various 
values of BL, BR and Out. In each case, the projected JFP-constraint is posted to 
the SICStus TV-solvev. 
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As a concrete example, when solving the conjunctive goal X #== RX, RX > 4.3, 
line (11) in the Prolog code for > just explained will eventually work for solving the 
right subgoal. In this case, viewing RX as HL and 4 . 3 as HR, the value computed for 
BL will be true because the bridge X #== RX will be available in the mixed store, 
and FDHL will be X. On the other hand, the value computed for BR will be false, 
and the value of FDHR will be computed as [4 . 3j , i.e. 4. Applying the proper case in 
Table [6l the projected constraint X #> 4 will be posted to the SICStus JFP-solver. 

5 Performance Results 

In this section we study the performance of the systems TOy ( Are nas et al. 20071 
lEstevez-Martm et al. 2008)) and META-S (jFrank et al. 2003al IFrank et al. 2003bl 
IFrank et al. 2005|) . i.e., the closest related approach we are aware of, when solving 
various problems requiring domain cooperation. After presenting a set of bench- 
marks in the first subsections, the three following subsections deal with an analysis 
of the benchmarks in each of the two systems and an a comparison between both. 

5.1 The Benchmarks 

We have selected a reasonably wide set of benchmarks which allows to analyze what 
happens when the set of constraints involved in the formulation of a programming 
problem is solved differently depending on the combination of domains that are 
involved in their solving. A concise description of the benchmarks is presented 
below. 

• Donald (donald): A cryptoarithmethic problem with 10 TV variables, one 
linear equation, and one alldifferent constraint. It consists of solving the equa- 
tion DONALD + GERALD = ROBERT. 

• Send More Money (smm): Another cryptoarithmethic problem with 8 
TV variables ranging over [0,9], one linear equation, 2 disequations and one 
alldifferent constraint. It consists of solving the equation SEND + MORE = 
MONEY. 

• Non-Linear Crypto- Arithmetic (nl-csp): A problem with 9 TV variables 
and non- linear equations. 

• Wrong- Wright ( wwr) : Another cryptoarithmethic problem with 8 TV vari- 
ables ranging over [1,9], one linear equation, and one alldifferent constraint. 
It consists of solving the equation WRONG + WRONG = RIGHT. 

• 3 x 3 Magic Square (mag.sq.): A problem that involves 9 TV variables 
and 7 linear equations. 

• Equation 10 (eq.10): A system of 10 linear equations with 7 TV variables 
ranging over [0,10]. 

• Equation 20 (eq.20): A system of 20 linear equations with 7 TV variables 
ranging over [0,10]. 

• Knapsack (knapsack) : A classical knapsack problem taken from (Hooker 2000) . 
We considered two versions: One as a constraint satisfaction problem (labeled 

as csp) and another one as an optimization one (labeled as opt). 
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• Electrical Circuit (circuit): A problem taken from (Hofstcdt 2000a), in 
which one has an electric circuit with some connected resistors (i.e., TZ vari- 
ables) and a set of capacitors (i.e., TV variables). The goal consists of knowing 
which capacitor has to be used so that the voltage reaches the 99% of the final 
voltage between a given time range. 

• bothln (goal2): The problem of solving the goal presented as Goal 2 in 
Subsection 1 1 . 21 for several values of n. Instances goal2(n) of this benchmark 
correspond to solving an instance of Goal 2 for the corresponding n. 

• bothln (goal3): The problem of solving the goal presented as Goal 3 in 
Subsection 11.21 for several values of n. Instances goal3(n) of this benchmark 
correspond to solving an instance of Goal 3 for the corresponding n. 

• Distribution (distrib). An optimized distribution problem involving the 
cooperation of the domains TZ and TV. The problem deals with a communi- 
cation network where NR continuous and ND discrete suppliers of raw material 
have an attached cost to be minimized (see Appendix 8 in (| Arenas et al. 2007[> ). 
The global optimum is computed. The various instances distrib (ND.NR) of 
this benchmark correspond to different choices of values for ND and NR. 

All the benchmarks were coded using TV variables and most of them demand the 
solving of (non-)linear equations. Only the last four of them strictly require cooper- 
ation between TV and TZ and cannot be solved by using just one of these domains. 
However, the rest of the benchmarks are also useful to evaluate the overhead in- 
troduced when the different solvers are enabled. The formulation of benchmarks 
nl-csp, mag.sq, circuit and smm was taken from the distribution of META-S. 
Full details and code of the benchmarks (written in both TOy and META-S) are 
available at http://www.lcc. uma.es/^afdez/cflpfdr/. 

All the benchmarking process was done using the same Linux machine (under the 
professional version of Suse Linux 9.3) with an Intel Pentium M processor running at 
1.70GHz and with a RAM memory of 1 GB. In the rest of this section, performance 
numbers, in milliseconds, have been computed as the average result of ten runs for 
each benchmark. In all tables, the best result obtained for each benchmark among 
those computed under the various configurations has been highlighted in boldface. 

5.2 Benchmark Analysis in TOy 

In this section we briefly present empirical support for two claims: a) that the 
activation of the cooperation mechanism between TV and 1Z does not penalize the 
execution time in problems which can be solved by using the domain TV; and b) 
that the cooperation mechanism using projections helps to speed-up the execution 
time in problems where both the domain TV and the domain 1Z are needed. 

Tables [9T I12I show the performance of each benchmark for several configurations 
of the TOy system, as explained below. The first column in each table displays the 
name of the benchmark to be solved, and the next columns corresponds to different 
activation modes of the TOy system, namely: 

• TOy {TV), an activation mode where the TV solver (but not the TZ solver) 
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is enabled. Actually, this corresponds to an older version of the TOy system 
which did not provide simultaneous support for ^-constraints. 

• TOy (TV + 11), an activation mode where both the TV solver and the 1Z 
solver are enabled, but the projection mechanism is disabled. 

• TOy (TV + IV) , an activation mode where the TV solver, the 1Z solver and 
the projection mechanism are all enabled. 



TT> Constraint Solving 



| TOy (TV) | TOy (TV + 72) | TOy (TV + 72) p | 



BENCHMARK 


naive 


ff 


naive 


ff 


naive 


ff| 


donald 


1078 


195 


1040 


188 


7476 


678 




smm 


16 


15 


14 


16 


47 


49 




nl-csp 


15 


20 


15 


18 


39 


86 




wwr 


18 


19 


18 


19 


58 


52 




maq.sq. 


92 


91 


89 


89 


87 


91 




eq.10 


74 


90 


74 


81 


284 


261 




eq.20 


138 


134 


139 


131 


431 


421 




knapsack (csp) 


5 


5 


5 


5 


5 


5 




knapsack (opt) 


40 


15 


35 


15 


70 


40 





Table 9. Solving TV Benchmarks in TOy (First Solution Search). Overload eval- 
uation. 

The heading 'TV Constraint Solving' in Table[5]mdicates that all the benchmarks 
have been formulated in such a way that all the constraints needed to solve them are 
submitted to the TV solver and the 1Z solver is not invoked. Note that although the 
activation mode TOy(TV) is sufficient to execute all the benchmarks presented in 
this table, the benchmarks have been also executed in the modes TOy(TV + 1Z) 
and TOy (TV + lZ) p with the aim of analyzing the overhead caused by the ac- 
tivation of these more complex modes when solving problems that do not need 
them. 

The heading 'TV ~ 1Z Constraint Solving' in Tables [T0lfT2l indicates that the 
formulations of the benchmarks require both the TV solver and the 1Z solver to 
be enabled; more precisely, although the benchmarks shown in Table [10] admit a 
natural formulation that can be totally solved by the TV solver, we have used 
an alternative formulation in which the (non-)linear constraints were submitted to 
the 1Z solver, whereas the rest of the constraints were sent to the TV solver; also 
solving the benchmarks shown in Tables [IT] and [12] strictly requires cooperation 
between TV and 1Z. These tables only consider the two activation modes of the 
TOy system which make sense for such benchmarks, namely TOy(TV + 1Z) and 
TOy(TV + lZ) p . 

Tables I91IT21 also include two columns corresponding to two different labeling 
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strategies: naive, in which TV variables are labeled in a prefix order (i.e., the left- 
most variable is selected); and first fail (ff), in which the TV variable with the 
smallest domain is chosen first for enumerating. Combined with the distinct acti- 
vation modes, this yields a number of configurations (i.e., six in Table [9] and four 
in the rest). 



TT> ~ 1Z Constraint Solving 



TOy '{TV + 1Z) | TOy{TV + TZ) p 



BENCHMARK 


naive 


ff 


nai've 


ff 


donald 


304970 


288700 


8305 


727 


smm 


22528 


22627 


41 


40 


nl-csp 


411 


383 


44 


87 


wwr 


411 


420 


54 


58 


maq.sq. 


166 


168 


158 


163 


eq.10 


266 


271 


290 


269 


eq.20 


402 


408 


433 


397 


knapsack (csp) 


5 


5 


5 


5 


knapsack (opt) 


16 


15 


11 


14 



Table 10. Solving TV ~ TZ Benchmarks in T Oy (First Solution Search). Evalua- 
tion of the constraint projection mechanism. 

Inspection of Table [5] reveals that the performance of all the benchmarks does not 
get worse when moving from T Oy{TV) to T Oy{TV + K) and T Oy{TV + TZ) , 
and it even improves in some cases. For those benchmarks that are most naturally 
coded in the domain TV (as, for instance, smm, wwr and mag.sq) the best results 
are not those obtained in TOy(TV + 7Z) p , but even in such cases the appreciable 
overload is not a great one. 

Inspection of Tables \W\ and [TT] reveals that the projection mechanism causes a 
significant speed-up of the solving process in most cases. Note that this mechanism 
behaves specially well in solving the goal2(n) and goal3(n) benchmarks, where the 
running time is stabilized in the range between 11 ms and 17 ms when projections 
are enabled. Significant speed-ups (i.e., at least two or more magnitude orders) are 
also detected in donald and smm benchmarks as well as in the different distrib 
benchmark instances. 

Finally, Table [12] presents the results corresponding to computing all the results 
for the last five benchmarks in Table 1111 The execution times are naturally higher 
than those shown in Table fTTl where only first solutions were computed. However, 
the significant speed-up caused by the activation of projections remains clearly 
observable. 
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TT> ~ 1Z Constraint Solving 



TOy {TV + 11) I TOy{TV + TZ) p 



BENCHMARK! naive ff nai've ff 



circuit 


14 


13 


14 


20 


distrib (2,5.0) 


662 


506 


144 


504 


distrib (3,3.0) 


1486 


810 


132 


814 


distrib (3,4.0) 


2098 


1290 


156 


1178 


distrib (4,5.0) 


20444 


12670 


240 


12744 


distrib (5,2.0) 


29108 


5162 


198 


7340 


distrib (5,5.0) 


141734 


85856 


272 


86497 


distrib (5,10.0) 


568665 


464230 


474 


462980 


goal2 (100) 


25 


28 


14 


14 


goal2 (200) 


40 


44 


13 


15 


goal2 (400) 


70 


72 


12 


13 


goal2 (800) 


131 


135 


12 


15 


goal2 (10000) 


704 


713 


14 


16 


goal2 (20000) 


1271 


1270 


12 


16 


goal2 (40000) 


2325 


2333 


11 


16 


goal2 (80000) 


4452 


4472 


13 


16 


goal2 (200000) 


10725 


10781 


13 


15 


goal3 (100) 


18 


20 


15 


16 


goal3 (200) 


26 


28 


13 


13 


goal3 (400) 


41 


44 


15 


16 


goal3 (800) 


75 


77 


16 


17 


goa!3 (5000) 


354 


360 


14 


16 



Table 11. Solving TV ~ TZ Benchmarks in T Oy (First Solution Search). Evalua- 
tion of the constraint projection mechanism on benchmarks necessarily demanding 
solver cooperation. 



5.3 Benchmark Analysis in META-S 

In this subsection, we present the results of executing benchmarks in META-S, a 
flexible meta-solver framework that implements the ideas proposed in (jHofstedt 2001; 



Hofstedt and Pepper 2007 ) for the dynamic integration of external stand-alone solvers 
to enable the collaborative processing of constraints. As already mentioned in Sec- 
tions [1] and [3l the cooperative framework underlying META-S bears some analogies 
with the approach described in this paper. Both META-S and TOy provide means 
for different numeric constraints domains to cooperate. TOy supports cooperation 
between the domains TL, TV and TZ, while META-S connects several kind of solvers, 
such as: 



• A TV solver (for floats, strings, and rationals) that was implemented in 
Common Lisp using as reference a library of routines for solving binary con- 
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TT> ~ 1Z Constraint Solving 



TOy '(TV + 11) I TOy(TV + TZ) p 



BENCHMARK 


nai've 


ff 


nai've 


ff 


goal3 (100) 


673 


625 


265 


242 


goal3 (200) 


1867 


1844 


329 


352 


goal3 (400) 


6527 


6573 


583 


579 


goal3 (800) 


24460 


24727 


976 


994 


goa!3 (5000) 


911880 


920670 


5365 


6135 



Table 12. Solving goal3(n) Benchmarks in TOy (All Solutions Search). 

straint satisfaction problems provided by Peter van Beck and available from 
http : //www . ai .uwaterloo . ca/^vanbeek/ software/ csplib . tar .gz. 

• A solver for linear arithmetic, i.e., the constraint solver LINAR described 
in (Krzikalla 1997). This solver is based on the Simplex algorithm and was 
implemented in the language C. It handles linear equations, inequalities, and 
disequations over rational numbers. 

• An interval arithmetic solver, that uses the sound math library (available 
at http://interval.sourceforge.net/interval/index.html), an ANSI 
C library implemented on the basis of the solver for interval arith- 
metic of Timothy J. Hickey from Brandeis University (available from 
http : //www . cs .brandeis . edu/^tim/). 

The interested reader is referred to (jFrank and Mai 2002) for more details on 
the META-S solvers. There are also some other significant differences between 
both systems. META-S is implemented in Common Lisp whereas TOy is imple- 
mented in Prolog. In contrast to TOy, META-S does not support different acti- 
vation modes (corresponding to T Oy{TV), T Oy{TV + K) and T Oy{TV + TZ) p 
in TOy), neither explicit labeling strategies, nor facilities for optimization. On 
the other hand, META-S supports the choice of different constraint solving strate- 
gies ([Frank et al. 2007), which is not the case in TOy. More details regarding the 
comparison between TOy and META-S can be found in Subsection 15.41 

We have investigated the performance of META-S in solving the benchmarks 
already considered for TOy in the previous section and the performance results 
are shown in Tables I13H14I The organization of rows and columns is also similar to 
the TOy tables (but considering the two different strategies explained below). The 
occurrences of the symbol '— ' indicate that the corresponding benchmark (namely, 
the knapsack optimization and the distribution problem) could not be executed 
because the META-S system provides no optimization facilities; the term 'error' 
corresponds with a failure returned by the system, that was not able to solve the 
goal. We have used the version 1.0 of META-S (kindly provided by its implementors 
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on our request) compiled using SuSE Linux version 9.3 (professional version), based 
on CMU Common Lisp 18d. 



META-S 



eager j heuristic 



BENCHMARK 


standard 


ordered 


standard 


ordered 


donald 


268510 


469370 


5290 


6140 


smm 


950 


620 


590 


580 


nl-csp 


344800 


1230 


302314 


970 


wwr 


10930 


650 


620 


620 


maq.sq. 


1160 


1220 


520 


540 


eq.10 


60 


60 


70 


70 


eq.20 


60 


60 


70 


70 


knapsack (csp) 


60 


60 


70 


70 


knapsack (opt) 










distrib (2,5.0) 










distrib (3,3.0) 










distrib (3,4.0) 










distrib (4,5.0) 










distrib (5,2.0) 










distrib (5,5.0) 










distrib (5,10.0) 










circuit 


70 


70 


70 


70 


goal2 (100) 


330 


330 


330 


330 


goal2 (200) 


730 


740 


740 


740 


goal2 (400) 


2340 


2340 


2340 


2350 


goal2 (800) 


8550 


8540 


8560 


8560 


goal3 (100) 


410 


410 


460 


460 


goal3 (200) 


900 


900 


1080 


1080 


goal3 (400) 


2870 


2880 


3520 


3540 


goal3 (800) 


10630 


10720 


13140 


13370 



Table 13. Solving the Benchmarks in META-S (First Solution Search). 

For the META-S benchmarks we have utilized the combination of the TT> solver 
(usually for rationals) and an arithmetic solver which was found analogous to the 
TT> plus 1Z combination used in the corresponding TOy benchmark. In fact, for 
META-S, we have selected the linear arithmetic solver since the interval arithmetic 
solver yielded poorer results in all cases. In addition, we have considered the best 
problem formulation (in terms of the target solver for each constraint) that yielded 
the best running time. Moreover, we have executed each META-S benchmark under 
four different constraint solving strategies: 

• Standard eager, in which all constraint information is propagated as early as 
possible. 
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• Ordered eager, working as the previous one complemented with user-given 
information for determining the order of projection operations. 

• Standard heuristic, working as the standard eager strategy complemented 
with an heuristic for giving priority to those variable bindings more likely to 
lead to failure. 

• Ordered heuristic, working as the previous one complemented with user-given 
information for determining the order of projection operations. 

In certain form, naive and ff labeling in TOy are similar, respectively, to eager 
and heuristic strategies in META-S. For the sake of a fair comparison, whenever 
possible we have encoded the META-S benchmarks using exactly the same problem 
formulations as well as the same constraints that were used in the corresponding 
TOy benchmarks. Benchmarks were coded using the functional logic language 
FCLL of META-S. Also, we took care that the variable orders were identical for 
the different resolution/labeling strategies in both systems. 



META-S 



| eager j heuristic 

BENCHMARK I standard ordered I standard ordered 



goal3 (100) 8930 8880 6940 6940 

goal3 (200) 60700 60870 47190 46880 

goal3 (400) 453330 459980 346930 348900 

goal3 (800) error error error error 



Table 14. Solving goal3(n) Benchmarks in META-S (All Solutions Search). 

Note that the META-S benchmarks shown in Table [H] (resp. Table [0} corre- 
spond to the TOy benchmarks in Tables IMTT1 (resp. Table [T^|) . all of which refer 
to first solution search (resp. all solutions search). 

5.4 TOy versus META-S 

The tables displayed in this subsection are intended to compare the performance of 
TOy and META-S. Table IT51 compares the behaviour of both systems when com- 
puting the first solution of various benchmarks, while the results in Table [TH] corre- 
spond to the computation of all the solutions for a few instances of the benchmark 
goal3(n). More precisely, the execution times and META-S jTOy rates displayed 
in Table IT51 correspond to the best results for each benchmark under those obtained 
for the various configurations in Tables ITOirTTl and [13l respectively; while Table [16] 
has been built from the information displayed in Tables [T2l and [Ml in a similar way. 
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SYSTEM 


Toy 


META-S 


META-S/T Oy 


donald 


188 


5290 


28.13 


smm 


14 


580 


41.42 


nl-csp 


15 


970 


64.66 


wwr 


18 


620 


34.44 


maq.sq. 


87 


520 


5.97 


eq.10 


74 


60 


0.81 


eq.20 


131 


60 


0.45 


knapsack (csp) 


5 


60 


12 


knapsack (opt) 


11 






circuit 


13 


70 


5.38 


goal2 (100) 


14 


330 


23.57 


goal2 (200) 


13 


730 


56.15 


goal2 (400) 


12 


2340 


195.00 


goal2 (800) 


12 


8540 


711.66 


goal3 (100) 


15 


410 


27.33 


goal3 (200) 


13 


900 


69.23 


goal3 (400) 


15 


2870 


191.33 


goa!3 (800) 


16 


10630 


664.375 



Table 15. Solving Benchmarks in TOY vs. META-S (First Solution Search) 



The analogies and differences between the domain cooperation mechanisms sup- 
ported by TOy and META-S have been discussed at the end of Subsection 13.31 
In both cases, projections play a key role, and the information displayed on Tables 
1151 and \W\ allows mainly to draw conclusions on the computational performance 
of both systems. META-S seems to behave particularly well in the solving of lin- 
ear equations, especially when the problem requires no global constraints (such as 
an alldifferent constraint used in benchmarks eqlO and eq20). The reason maybe 
two- fold: First, that the linear arithmetic solver of META-S performs better than 
its TV solver, and, second, that flattening a nested constraint in TOy generates 
as many flat constraints as the number of operators it includes. 

However, in general, TOy shows an improvement of about one order of magni- 
tude with respect to the META-S system, for the benchmarks used in our compari- 
son. As an extreme case, the computation time for obtaining the first solution of the 
benchmark goal3(800) increases more than three orders of magnitude with respect 
to TOy, and computing all the solutions for this benchmark in META-S does not 
succeed. In certain form, the experimental results suggest that our proposal is not 
only promising but also interesting in its current state. 

In any case, the 'superior' performance of TOy with respect to META-S has to 
be interpreted carefully. One reason for TOy's advantage may be that the numer- 
ical solvers connected in the current version of META-S have been implemented 
just to experiment with the concepts of the underlying theoretical framework de- 
scribed in (jHof stcdt 2001; Hofs tedt and Pepper 20 07), without much concern for 
optimization, while TOy relies on the optimized solvers provided by SICStus Pro- 
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SYSTEM 


Toy 


META-S 


META-S/TO^ 


goal3 (100) 


242 


6940 


28.67 


goal3 (200) 


329 


46880 


142.49 


goal3 (400) 


579 


346930 


599.18 


goal3 (800) 


976 


error 





Table 16. Solving goal3(n) in TOY vs. META-S (All Solutions Search) 



log. Another advantage of TOy is the availability of global constraints such as 
alldifferent, that are lacking in META-S. Admittedly, a better comparison of the 
performance results in both systems would be obtained by comparing indepen- 
dently the integrated solvers in each of the systems, and then normalizing the 
global results for the systems; or alternatively, by connecting the same solvers to 
both systems. This would be possible if all the integrated solvers were effectively 
black-boxes that can be unplugged from the systems. Unfortunately, this is not the 
case, as the solvers attached to TOy are used as provided by SICStus Prolog and 
they were not internally adjusted to work in a cooperation system, whereas the 
solvers used in META-S were implemented with regard to their integration into the 
implementation of META-S as a system with cooperating components. 

In favor of META-S, we mention that the cooperation model proposed in META- 
S seems to be more flexible than the cooperation model currently implemented in 
TOy, and provides facilities not yet available in TOy. For instance, META-S al- 
lows to integrate and/or redefine evaluation strategies (Frank et al. 2003b) whereas 
TOy relies on a fixed strategy for goal solving and constraint evaluation. Also, 
the projection mechanism currently implemented in TOy is less powerful than in 
META-S, because projections cannot be applied to the constraints inside the con- 
straint stores. Finally, META-S enables the integration of different host languages 
(|Frank et a l. 2005), whereas the CCLNC(C) goal solving calculus implemented in 
TOy is intended for declarative languages fitting the CFLP scheme. 

6 Related Work 

In this section, in addition to already mentioned related works, we extend the discus- 
sion to other proposals developed in the area of cooperative constraint solving. Of 
course, the issues of communication and cooperation are relevant to many aspects of 
computation. Here, we discuss a selection of the literature concerning proposals for 
communication and cooperation in constraint and declarative programming. Exist- 
ing cooperative systems are very diverse and range from domain combinations to a 
mix of distinct techniques for solving constraints over the same domain. Moreover, 
the cooperating systems may be very different in nature: Some of them perform 
complete constraint solving whereas others just execute basic forms of propagation. 
In general, depending on the nature of the cooperation, we catalogue cooperative 
constraint solving in four non-disjoint categories: 
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1. Cooperation of (built-in) domains coexisting in the same system. 

2. Interchange of information between different solvers/domains via special con- 
structs. 

3. Interoperability or communication between independent solvers. 

4. Combination or integration of entities with distinct nature (i.e., methods 
and/or solvers based on different algorithms, or languages with different res- 
olution mechanisms). 

In the following four subsections we discuss some of the relevant work done in 
each of these categories, as well as their relation to our own approach. 

6.1 Cooperation of (Built-in) Domains Coexisting in the Same System 

There are a number of constraint systems that provide support for the interaction 
between built-in and predefined domains. In these systems, a solver is viewed as a 
device that transforms the original set of constraints to an equivalent reduced set. 
As examples, we can cite the following systems: 

• CLP(BNR) (|Benhamou and Older 1997|) . Prolog III (jColmerauer 1990P and 
Prolog IV (N'Don g 1997[ ) allow solver cooperation, mainly limited to booleans, 
reals and naturals (as well as term structures such as lists and trees). 

• The language NCL ((Zhou 2000) provides an integrated constraint framework 
that strongly combines boolean logic, integer constraints and set reasoning. 
Currently, NCL also integrates efficient CP domain cutting techniques and 
OR algorithms. 

Most existing systems of this kind have two main problems: firstly, the coopera- 
tion is restricted to a limited set of computation domains supported by the system; 
and secondly, the cooperation mechanism is very dependant on the involved compu- 
tation domains and thus presents difficulties to be generalized to other computation 
domains. 

Our computational model for the cooperation of the domains TL, TT> and 1Z 
and its current TOy implementation can be catalogued in this category, and in- 
sofar it shares the two limitations just mentioned. However, our approach is more 
general because it is based on a generic scheme for CFLP programming over a 
parametrically given coordination domain C. The cooperative goal solving calcu- 
lus CLNC(C) presented in Section [3] refers to the particular coordination domain 
C = M. (&Tt © TT>®'R. 1 but it can be easily extended to other coordination domains, 
as sketched in our previous paper (jEstevcz-Mart m et al. 20 07). 

6.2 Interchange of Information between Computation Domains and/ or 

Solvers via Special Constructs 

Another cooperation technique consists of providing special built-in constructs de- 
signed to propagate information among different computation domains that coexist 
in the same system. For example, this is the case with the reified constraints that 
enable a communication between arithmetic computations and a Boolean domain. 
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Within this type of cooperation we can cite Conjunto (Gervet 1997), a constraint 
language for propagating interval constraints defined over finite sets of integers. This 
language provides so-called graduated constraints which map sets onto arithmetic 
terms, thus allowing a one-way cooperative channel from the set domain to the 
integer domain. Graduated constraints can be used in a number of applications 
as, for instance, to handle optimization problems by applying a cost function to 
quantifiable terms (i.e., arithmetic terms which are associated to set terms). 

Also, a generic framework for defining and solving interval constraints on any set 
of domains (finite or infinite) with a lattice structure is formulated in (Fernandez and Hill 2004; 
Fernandez and Hill 2006). This approach also belongs to the cooperation category 
described in Subsection 16.11 It enables the construction of new (compound) con- 
straint solvers from existing solvers using lattice combinators, so that different 
solvers (possibly on distinct domains) can communicate and cooperate in solving 
a problem. The clp(C) language presented in (Fernandez and Hill 2004) is a proto- 
type implementation of this framework and allows information to be transmitted 
among different (possibly user-defined) computation domains. 

Our proposal in this paper can be also considered to fit into the special constructs 
category, by viewing bridge constraints as channels that enable the propagation of 
information between different computation domains. 

6.3 Interoperability 

A number of recent publications deal with approaches to solver cooperation requir- 
ing interoperability, understood as the behaviour of some coordinating system that 
supports communication between several autonomous systems. In such settings, co- 
operation relies on suitable interfaces, which have to be specified and implemented 
according to the specific formats required by the various domains and solvers. 

For instance, (jGoualard 2001|) proposes a C++ constraint solving library called 
aLiX for communicating between different solvers, possibly written in different lan- 
guages. Two of the main aims of aLiX are to permit the transparent communication 
of solvers and ensure type safety, that is to say, the capacity to prevent a priori 
the connection of a solver that does not conform to the input format of the inter- 
face with another solver. The current version of aLiX is not mature yet, although 
its interoperability approach offers interesting possibilities. One of the main short- 
comings of the current aLiX version is that a component for solving continuous 
constraints is not yet integrated into the system, and thus real constraints cannot 
be processed. 

In the same spirit, many constraint systems provide both a linear and a non-linear 
solver for the real domain. As the linear solver is more efficient of the two, it should 
be used whenever the constraints are linear, and there is a need for communica- 
tion between the two real solvers. As an example, (Monfroy et al. 1995Q describes a 
client/server architecture to enable communication between the component solvers. 
This consists of managers for the system and the solvers that must be defined on 
the same computational domain (the real numbers, for example) but with differ- 
ent classes of admissible constraints (i.e., linear and non-linear constraints). The 
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constraint logic programming (CLP) system CoSAc is an implementation of this 
architecture. A built-in platform permits the integration and connection of the 
components. The exchange of information is managed by means of pipes and the 
exchanged data are character strings. One of the main drawbacks of this system is 
the lack of type safety. Moreover, the cooperation happens at a fixed level that pre- 
vents the communication of solvers in a transparent way, since the solvers cannot 
obtain additional information from the structure of the internal constraint store. As 
already discussed at the end of Subsection 13.31 the current TOy implementation 
of our cooperative computation model suffers from a similar limitation, preventing 
the constraints already placed into the J-T> and 1Z stores to be projected. This issue 
should be addressed in future improvements of our system. 

As CoSAc does not permit solver combination, Monfroy designed a domain in- 
dependent environment for solver collaboration, and he used this concept in order 
to unify solver cooperation and combination. Basically, solver cooperation means 
the use of several solvers with data exchange between them, whereas solver com- 
bination is understood as the construction of new solvers from other previously 
defined solvers. In his PhD thesis (Monfroy 1996:), Monfroy developed the system 
BALI (Binding Architecture for Solver Integration) that facilitates the integration 
of heterogeneous solvers as well as the specification of solver cooperation via a num- 
ber of cooperation primitives. Monfroy's approach assumes that all the solvers work 
over a common store, while our own proposal requires communication among differ- 
ent stores. Monfroy also designed SoleX ( jMonfroy and Ringciss en 1999| ), a domain- 
independent scheme for constraint solver extension. This schema consists of a set 
of rules for transforming constraints that cannot be managed by a solver into con- 
straints that can be treated by that solver, thus extending the range of solvable 
constraints. Unfortunately, as commented in (Monfroy 1996| (page 195), SoleX and 
BALI were not integrated. Such an integration could lead to a framework including 
both solver collaboration and solver extension. 

The interoperability category also includes a line of research dealing with the 
development of coordination languages, aiming at the specification of cooperation 
between solvers. There exist several proposals whose main goal is to study the use 
of control languages to specify elementary constraint solvers as well as the collabora- 



tion of solvers in a uniform and flexible way. For instance, ( Arbab and Monfroy 1998 ) 
proposes to use the coordination language MANIFOLD for improving the constraint 
solver collaboration language of BALI. More recent works such as ( jMonfroy and Castro 2004 



Castro and Monfroy 2004) aim at providing means of designing strategies that are 
more complex than simple master-slave approaches. Basically, Castro and Monfroy 
propose an asynchronous language composed of interaction components that con- 
trol external agents (in particular solvers) by managing the data flow. A software 
framework for constructing distributed constraint solvers, implemented in the coor- 
dination language MANIFOLD, has been described in (Zoetewcij 2003). A different 
point of view regarding solver cooperation is analyzed in QPajot a nd Monfroy 2003 ) , 
where a paradigm to enable the user to separate computation strategies from the 
search phases is presented. 
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Also it is worth mentioning the project COCONUT0 whose goal was to integrate 
techniques from mathematical programming, constraint programming and interval 
analysis (and thus it can also be catalogued in the category of cooperation via 
techniques combination as described in Section [6]4]). A modular solver environment, 
that can be extended with open-source and commercial solvers, was provided for 
nonlinear continuous global optimization. This framework was also designed for 
distributed computing and has a strategy engine that can be programmed using a 
specific interpreted language based on Python. 

Mircea Marin has developed in his PhD thesis (jMarin 2000|) a CFLP scheme that 
combines Monfroy's approach to solver cooperation (Monfroy 1996) with a higher- 



order lazy narrowing calculus somewhat similar to ( Lopcz-Frag uas et al. 2004| and 
the goal solving calculus presented in Section [3] of this paper. In this setting, Mon- 
froy's ideas are used to provide various primitives for solver combination, and the 
CFLP scheme allows to embed the resulting solvers into a Functional and Logic 
Programming language. In contrast to our proposal, Marin's approach allows for 
higher-order unification, which leads both to greater expressivity and to less ef- 
ficient implementations. Another difference w.r.t. our approach is the intended 
application domain. The instance of CFLP implemented by Marin and others 
(jMarin et al. 2001]) combines four solvers over a constraint domain for algebraic 
symbolic computation. This line of research has been continued in works such as 
dKobayashi et al. 2001HKobayashi et al. 2002[|Kobayashi et al. 2003HKobayashi 2003| . 
These papers describe a collaborative CFLP system, called Open CFLP, which 
solves symbolic constraints by collaboration between distributed constraint solvers 
in an open environment such as Internet. The solvers act as providers of constraint 
solving services, and Open CFLP is able to use them without knowing their loca- 
tion and implementation details. The common communication infrastructure (i.e., 
the protocol) and the specification language were implemented using CORBA and 
MathML respectively. 

Another recent proposal for the combination of solvers in a declarative program- 
ming language can be found in (jde la Banda et al. 2001[) . This paper deals with 
the construction of solvers in the HAL system, which supports the extension of 
existing solvers and the construction of hybrid ones. HAL provides semi-optional 
type, mode and determinism declarations for predicates and functions as well as a 
system of type classes over which constraint solvers' capabilities are specified. In 
particular, HAL type classes can require that the types belonging to them must 
have a suitable associated constraint solver. 

A quite general scheme for solver cooperation fitting the interoperability cat- 
egory has been proposed by Hofstedt et al. in (jHofstedt 2000a; Hofst edt 2000bl 
IHofste dt 2001; Hofstedt and Pepper 2007). Here, constraint domains are formalized 



by using E-structures in a sorted language, constraints are modeled as n-ary rela- 
tions, and cooperation of solvers is achieved by two mechanisms: Constraint propa- 
gation, that submits a constraint belonging to its corresponding store; and projec- 



1 Sec http: //www. mat .univie . ac . at/ neum/glopt/coconut/ 
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tion of constraint stores, that consults the contents of a given store S-p and deduces 
constraints for another domain. Relying on these mechanisms, different constraint 
solvers (possibly working over different domains, and implemented in various lan- 
guages) can be used as components of an overall system, whose architecture provides 
a uniform interface for constraint solvers which allows a fine-grain formal specifica- 
tion of information exchange between them. This approach has been implemented 
in the system META-S (jFrank et al. 2003at IFrank et al. 2003bt IFrank et al. 2005[) . 
that supports the dynamic integration of arbitrary external (stand-alone) solvers to 
enable the collaborative processing of constraints. Some analogies and differences 
between this approach and our own have been discussed already at several places 
of this paper; see the Introduction, and sections 1331 and l5l 

As a more theoretical line of work related to the interoperability category, there 
are a number of formal approaches to the combination of constraint solvers on do- 
mains modeled as algebraic structures. This kind of research stems from a seminal 
paper by Nelson and Oppen (Nelson and Oppen 1979). More recent relevant work 
includes several papers by Baader and Schulz. For instance, (Baadcr and Schulz 1995) 
provides an abstract framework to combine constraint languages and constraint 
solvers and focuses on ways in which different and independently defined solvers 
may be combined. This paper does not really deal with the constraint cooperation 
mechanism, but it focuses in defining algebraic properties needed for the combina- 
tion of constraint languages and solvers. Later on, (jBaader and Schulz 1998) gen- 
eralized a proposal from a previous paper (jBaader and Schulz 1996) and presented 
a general method for the combination of constraint systems, which is is applicable 
to so-called quasi-structures. This general notion comprises various instances, such 
as (quotient) term algebras, rational trees, lists, sets, etc. The methods proposed 
in (jBaader and Schulz"l 996; Ba ader and Schulz 1998|) can be seen as extensions of 
previous approaches to the combination of unification algorithms for equational the- 
ories, viewing them as instances of constraint solvers ( jKirchner and Ri ngeissen 1992; 
|Kirchner and R iiigcisscn 1994). As pointed out in (Kcpscr and Richt s~T999[ ) , a weak 
point of these approaches is the lack of practical use. 

Our proposal can clearly be catalogued in the interoperability category, because it 
aims at the cooperation of several constraint domains equipped with their respective 
solvers. Our main communication mechanism, namely bridges, has the advantage 
of syntactic simplicity, while being compatible with the static type systems used by 
many declarative languages. Moreover, our notion of coordination domain allows 
us to use a generic scheme for CFLP programming as a formal foundation. 



6.4 Combining Methods and/or Solvers based on Different Algorithms 

One popular approach to cooperation consists of combining solvers or methods 
based on different algorithms. In this category we include the integration of different 
paradigms in one language. In the following, we provide a (non-exhaustive) list of 
proposals of this kind. 

For instance, one of the initial forms of cooperating constraint solving con- 
sisted of using different problem solvers (viewed as algorithms) to work individ- 
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ually over different sub-parts of an overall problem. This was the approach used 
in (jDurfee et al. 19 89) in order to integrate within a network a number of indi- 
vidual solvers intended to work over different parts of a problem. In a similar way, 
(jKhedro an d Gcneserc th 1994[) proposed a multi-agent model where each agent acts 
independently to solve a distributed set of constraints that constitutes a distributed 
constraint satisfaction problem. The paper ( |Hong 1 994) also studied the confluence 
of solvers to solve a common problem, suggesting to manage a set of algorithms 
each of which should be repeatedly applied on the problem until reaching a stable 
form. 

Within the area of Constraint Programming, (Benhamou 1996) described a uni- 
fied framework for heterogeneous constraint solving. Here, the cooperation comes 
from the combination of different algorithms, possibly defined over distinct struc- 
tures. The main idea is to represent the solvers as constraint narrowing operators 
(CNO) that are closure operators, and to use a generalized notion of arc-consistency. 
Conditions on the CNOs needed to ensure the main properties of the principal al- 
gorithm are identified. Solver communication involving shared common variables 
and sending and receiving information to each other is described. The paper also 
gives a fixed point semantics to describe the cooperation process. One of the main 
drawbacks of this proposal is that termination of the central algorithm relies on the 
finitcncss of an approximate domain A built as a subset of the powerdomain p(D) 
of the domain D under consideration, including D among its members and closed 
under intersection. For instance, termination cannot be guaranteed in case that D 
is the domain of sets of real numbers, which is useful for dealing with real interval 
constraints. 

In relation to the problem of solving real constraints, (Benham ou et al. 1 999) 
has proposed the combination of hull consistency and box consistency with the 
objective of reducing the computation time achieved by using box consistency alone. 
This idea was reflected in DecLic (jBenhamou et al. 19971 [Goualar d et al. 1999ft , a 
CLP language that mixes boolean, integer and real constraints in the framework 
of intervals. This system was shown to be fairly efficient on classical benchmarks 
but at the expense of decreasing the declarativity of the language as a consequence 
of allowing the programmer to choose the best kind of consistency to use for each 
constraint. 

The combination of interval techniques for solving non-linear systems is also tack- 
led in ( Granvilliers 2001), Granvilliers describes a cooperative strategy to combine 
the interval-based local consistencies methods (i.e., box and hull consistency) with 
the multi-dimensional interval Newton method and shows the efficiency of the main 
algorithm. 

Another proposal for developing a cooperation technique for solving large scale 
combinatorial optimization problems was described in (ICastro et al. 2004|) . This pa- 
per introduces a framework for designing cooperative strategies, describing a scheme 
for the sequential cooperation between Forward Checking and Hill- Climbing. A set 
of benchmarks for the Capacity Vehicle Routing Problem shows the advantages of 
using this framework, that always outperforms a single solver. 

The combination of linear programming solvers and interval solvers has also 
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been specially fertile in the last decades (jMarti and Ruchcr 1995). Many of the 
cooperating systems resulting from this combination have been implemented as 



(prototype) declarative systems, as e.g., ICE ( |Beringer and Backer 1995] ), Prolog IV 
dN'Dong 1997| , CIAL (IChiu and Lee 20021) and CCC (IRueher and Solnon 1997|) . 
among others. 

The integration of mathematical programming techniques in the CLP scheme 
(jvan Hoeve 2000p may be considered another form of cooperation that has been 
treated extensively in the literature; see e.g. the integration of Mixed Integer pro- 
gramming and CLP (jRodosek et al. 1997||Harjunkoski et al. 2000[lThorsteinsson 2001]) . 
the combination of CLP and Integer Programming (Bockmay r and Kasper 2000[ ) 
and the combination of CLP and Linear Programming (Vandecastcclc and Rodosck 1998), 
among others. 

The domain cooperation framework presented in this paper is quite generic, and 
its current implementation in TOy relies on the availability of black box solvers 
provided by SICStus Prolog flSICStus~Pr olog 2007}. Therefore, it cannot be cata- 
logued into the cooperation category considered in this subsection, which is very 
specific and relies on a detailed control of the techniques and solvers involved. Nev- 
ertheless, the work described in this subsection points to combination techniques 
which lead to improved performance and may be useful for future implementations 
of our approach. 

7 Conclusions and Future Work 

The work presented in this paper is aimed as a contribution to the efficient use 
of constraint domains and solvers in declarative languages and systems. We have 
investigated foundational and practical issues concerning a computational frame- 
work for the cooperation of constraint domains in Constraint Functional Logic 
Programming, using constraint projection guided by bridge constraints as the main 
cooperation tool. Taking a generic scheme as a formal basis, we have focused on a 
particular case of practical importance, namely the cooperation among the symbolic 
Herbrand domain TL and the two numeric domains 1Z and TT>. 

The relation to our previous related work and some pointers to related work by 
other researchers have been presented in Section [IJ and a more detailed discus- 
sion of the state-of-the-art concerning cooperation of constraint domains can be 
found in Section [6] In the rest of this section we give a summary of the main re- 
sults presented in the other sections of the paper, followed by some considerations 
concerning current limitations and possible lines of future work. 

7. 1 Summary of Main Results 

Our results include a formal computation model for cooperative goal solving in 
Constraint Functional Logic Programming, the development of an implemented 
system, and experimental evidence on the implementation's performance and its 
comparison with the closest related system we are aware of. More precisely: 

• In Section[2]we have presented a formal framework for the cooperation of con- 
straint domains in an improved version of an already existing CFLP scheme 
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for Constraint Functional Logic Programming. We have formalized a notion of 
constraint solver suitable for CFLP programming, as well as a mathematical 
construction of coordination domains, a special kind of hybrid domains built 
as a combination of several pure domains intended to cooperate. In addition 
to the facilities provided by their components, coordination domains supply 
special primitives for building bridge constraints to allow communication be- 
tween different component domains. As particular case of practical interest, 
we have formalized a coordination domain C — M. © TL © TV © TZ tailored 
to the cooperation of three useful pure domains: the Her brand domain TL 
which supplies equality and disequality constraints over symbolic terms, the 
domain TZ which supplies arithmetic constraints over real numbers, and the 
domain TV which supplies finite domain constraints over integer numbers. 
Practical applications involving more that one of these pure domains can be 
naturally treated within the CFLPiC) instance of the CFLP scheme. From 
a programmer's viewpoint, the domain TL supports generic equality and dis- 
equality constraints over arbitrary user defined datatypes, while TZ and TV 
provide more specific numeric constraints. 

• Section [3] presents a formal calculus for cooperative goal solving in CFLP(C). 
The main programming features available to CFLP(C) programmers include 
a Milner's like polymorphic type system, lazy and possibly higher-order func- 
tions, predicates, and the cooperation of the three domains witihin C. The 
goal solving calculus is presented as a set of goal transformation rules for 
reducing initial goals into solved forms. There are rules that use lazy nar- 
rowing to process program defined function calls in a demand-driven way, 
domain cooperation rules dealing among other things with bridges and pro- 
jections, and constraint solving rules to invoke the solvers of the various pure 
domains involved in the cooperation. The section concludes with theoreti- 
cal results ensuring soundness and completeness of the goal solving calculus, 
where completeness is guaranteed for well-typed solutions as far as permitted 
by the completeness of the underlying solvers and some other more technical 
requirements. 

• Section [4] presents the implementation of the cooperative goal solving calculus 
for CFLP(C) in a state-of-the-art declarative programming system. In addi- 
tion to describing general aspects such as the software architecture, we have 
focused on the implementation of domain cooperation mechanisms, illustrat- 
ing the correspondence between code generation in the implemented system 
and the goal transformation rules for cooperation formalized in the previous 
section. 

• Section [5] is devoted to performance analysis by means of a set of benchmarks. 
The experimental results obtained lead us to several conclusions. Firstly, we 
conclude that the activation of the domain cooperation mechanisms between 
TV and 1Z does not penalize the execution time in problems which can be 
solved by using the domain TV alone. Secondly, we also conclude that the 
cooperation mechanism using projections helps to speed-up the execution 
time in problems where a real cooperation between TV and 1Z is needed. 
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Thirdly, our experiments show a good performance of our implementation 
with respect to the closest related system we are aware of. In summary, we 
conclude that our approach to the cooperation of constraint domains has been 
effectively implemented in a practical system, that is distributed as a free 
open-source Sourceforge project (http://toy.sourceforge.net) and runs 
on several platforms. 

7.2 Some Current Limitations and Planned Future Work 

In the future we would like to improve some of the limitations of our current ap- 
proach to domain cooperation, concerning both the formal foundations and the 
implemented system. More precisely: 

• The cooperative goal solving calculus CCLNC(C) presented in Section [3] 
should be generalized to allow for an arbitrary coordination domain C in 
place of the concrete choice M © H © TV © TZ. This is a straightforward 
task. However, for the purposes of the present paper we found more appro- 
priate to deal just with the coordination domain supported by the current 
implementation. 

• The implemented system should be expanded to support some of these more 
general coordination domains, which could include specific domains for boolean 
values, sets, or different types of numeric values. More efficient and power- 
ful constraint solvers for such domains should be also integrated within the 
implementation. 

• CCLNC(C) should be also expanded to allow the computation of projections 
from the primitive constraints placed within the constraint stores. These more 
powerful projections were allowed in the preliminary version of CCLNC(C) 
presented in (|Estcvcz-Mart rn~et al. 2007)) . but they were not implemented and 
no completeness result was given. Currently, projections are computed only 
from the constraints placed in the constraint pool (see rule PP in Table [4] 
in Subsection 13. 3|) and the TOy implementation only supports this kind of 
projections. Allowing projections to act over stored constraints will require 
to solve new problems both on the formal level (where some substantial diffi- 
culties are expected for proving a completeness result) and on the implemen- 
tation level (where the current system will have to be modified to enable a 
transparent access to the constraint stores). 

• As a consequence of the previous improvement, the cooperative goal solving 
process will show more complicated patterns of interaction among solvers. 
Therefore, some means to describe goal solving strategies should be provided 
to enable users to specify some desired sequences of goal transformation rules, 
especially with regard to the activation of solvers and projections. In addition 
to being implemented as part of the practical system, goal solving strategies 
are expected to be helpful for proving the completeness of a cooperative goal 
solving calculus improved as described in the previous item. 

• The experimentation with benchmarks and application cases should be further 
developed. 
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• Last but not least, the implemented system should be properly maintained 
and improved in various ways. In particular, library management should be 
standardized, both with respect to loading already existing libraries and with 
respect to developing new ones. 
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Appendix A [Auxiliary Results and Proofs] 

This Appendix collects proofs of the results stated in Section [2] and Section [3] omit- 
ted from the main text. Some of them rely on previously stated auxiliary results, 
especially Lemmata [T] and [5] from Subsection 12.21 and Lemma [3] from Subsection 
12.31 In addition, some other auxiliary results will be included at the proper places. 



A.l Properties of Constraint Solvers and Coordination Domains 

The first part of the Appendix includes the proofs of the main results stated in 
Section [2j First we present the proof of Lemma[5j about general properties of proof 
transformation systems. 

Proof of Lemma [5| 

1. The transition relation Vrv.x of the sts generates a tree with root line, whose 
leaves correspond to the stores belonging to <S.Fx>(II, X). Since W~v,x is finitely 
branching and terminating, this tree is locally finite and has no infinite branches. 
By so-called Konig's Lemma (see ( |Baader and Nip kow 1998), Section 2.2) the tree 
must be finite. Therefore, it must have finitely many leaves, and SJ-t>{)A, X) is 
finite. For later use, we remark that solve® (II, X) can be characterized as 

\ v /{3Y 7 (n' □ a') | n □ e Yr v . x \ IT □ a', Y 7 = var(W □ a') \ var(U)} 

2. Assume that the sts has the fresh local variables property and the safe bind- 
ings property. Due to the remark at the end of item 1., for each Absolved form 
3Y' (U' O a') computed by the call solve (II, X) there is some sequence of ti~v,X 
steps 

such that H' n □ n' n = II' □ a' is irreducible, and the following conditions hold for 
all 1 < i < n: LTJ □ ^ is a store with fresh local variables Y? = varlli^ □ /j,^) \ 
var(Ii l i _ 1 □ fi'i_i)', n'i = for some substitution [i; L verifying vdom(\ii)\J\vran{]±i) 

C uar(II^_ 1 ) U Y(; and fJ-i(X) is a constant for all X 6 X n vdom(^i). Then, Y' = 
Y[, . . . , Y^, and an easy induction on n allows to prove that vdom(a') L)vran(o-') C 
var(H) U Y' and that (t'(X) is a constant for all X 6 X n vdom(a'). Therefore, the 
solver solve® also satisfies the fresh local variables property and the safe bindings 
property. 
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3. Assume that the sts is locally sound. Because of the remark in item 1., to prove 
soundness of solve it is sufficient to show that the union 

\J{Sol v (3Y 7 (n' □ a')) | n □ a Yr V . x \ II' □ cr', Y 7 = var{W D a') \ var (II □ cr)} 

is a subset of Sol-p (II Da). In order to show this, we assume 

II □ a H-£ : x \ n' □ cr', Y 7 = var(U' D a') \ var{U D a) 

and prove SoId(3Y' (II' □ cr')) C Sol-p(H D a) by induction on n: 
n — : In this case Y' = 0, II' □ a' = II □ a. The inclusion to be proved is trivial. 
n > : In this case II □ a Vr v ,x II'i □ cr[ H-g~^! II' □ a' for some store li^Ua^. 
Let Y 7 = var(n.' 1 na' 1 ) \ var (II □ cr) and Y 77 = var(W Da') \ var(n , 1 Da' 1 ). Then 
Y' = Y{, Y" = var(H' D a') \ var(H D a). By induction hypothesis, we can assume 
5oZ c (3F 77 (n' □ a')) C Sol v (U[ D a[). Then, for any given 77 £ 5o^ I3 (3F 7 (n' □ cr')) 
we can prove 77 6 Sol-p (riDcr) by the following reasoning: by definition of Sol-p, 
there is 77' 6 SoI-d{W D a') such that 77' =ypr V and hence 77' ^artnner) V- Triv- 
ially, it follows that 77' £ 5oZ c (3Y 77 (n' □ tr')), which implies 77' G SWx>(ni □ a [) 
by induction hypothesis. Trivially again, it follows that 77' £ S , o^(3Y 1 '(n' 1 Dei)) 
which implies 77' £ Sol-p (n □ cr) due to local soundness. Since 77' = va r(na a) we 
can conclude that 77 £ Solv(H □ a). 

4. Assume now a selected set 7^.5 of strs such that the sts is locally complete for 
7?.iS-free steps. Because of the remark in item 1., to prove completeness of solve® 
for 7^.5-free invocations it is sufficient to show that WTSoI-d(TI Da) is a subset of 
the union 

[J{WTSol v (3Y 7 (U' D a')) \ U D a Yr v . x \ II' □ a', Y 7 = var(U' D a') \ var{U D a)} 

under the additional assumption that II □ a is hereditarily 7?.<S-irreducible. This 
can be viewed as a property of the store II □ a that can be proved by well-founded 
induction (see again ( |Baader and Nipkow 1998D , Section 2.2) on the terminating 
store transformation relation H~-p x : 

Base Case : n □ a is irreducible w.r.t. Vrv,x- In this case, the union reduces to the 
set WTSol-p(H D a) and the inclusion to be proved is trivial. 

Inductive Case : n □ a is reducible w.r.t. Vrv.x- In this case, since n □ cr is hered- 
itarily 7^.5-irreducible and the sts is locally complete for 7?.iS-free steps, for any 
77 £ WT 'Solx>(H D a) there is some hereditarily 1ZS- irreducible (H[ □ a[) such that 
n □ cr H - 7J, x U' 1 Da' 1 and 77 £ WTSol- D (3Y 7 (W 1 Da[)) where Y{ = var (U^ Da[) \ 
var(U D a). Then, by definition of Solv, there is 7^ £ WTSoI-d^ D a[) such that 
i][ =\— V- The induction hypothesis can be assumed for Tl[ D a[, and there must be 
some n' □ cr' such that Ili □ a[ Yr Vi x \ n' □ cr', Y 77 = var(Ii' D a'^var^Da^) and 
?7i £ WTSohiBY 77 ^' D cr')). By definition of Sol v , there is 77' £ WTSol v (n' D a') 
such that 77' =\— ■q' 1 . Moreover, we get UDa \h v . x l II' Da' and Y 7 =Y[,Y 77 = 
var(W D a')\var{Tl D a) such that 77' 77, and thus 77 £ WTSol v (3Y 7 {Il' D a')). 
This completes the proof of the Lemma. □ 

Table IA II displayed in the next page and the two auxiliary Lemmata stated and 
proved immediately afterwards will be used in the subsequent proof of Theorem 
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[T] the main result in this subsection. It ensures that solve l ~ L satisfies the require- 
ments for solvers listed in Definition [6] (except for a technical limitation concerning 
completeness). The proof of this theorem also relies on Lemma [5j 

Lemma 7 {Auxiliary Soundness Lemma) 

Assume II C PCon-p and a, o~i £ Sub-p such that a is idempotent and Ilcr = II. 
Then Sol v (nai) n Sol-oiaat) C Sol-p{Tl) n Sol v {a). 
Proof of Lemma [7] 

The hypothesis of the Lemma say that a — aa and Ha = II. On the other hand, 
because of the Substitution Lemma [3] and the definition of Sol-p, any r\ £ Val-p 
verifies 77 £ Solr>(Tlai) Pi Sol-p{aa\) iff ait] £ Sol-p{H) and aa\rj = rj. Therefore, to 
prove the lemma it suffices to assume 

(a) a = aa ib) Ha = IT (c) ain £ Sol-p{H) (d) aa\n = n 

and to deduce from these assumptions that r\ £ Solp{H) PI Sol-p{a). 

First we prove that 77 £ S'oZ-D(n) as follows: by (c) and (6), we obtain a\r\ £ 
SW£>(n<7), which amounts to a a in £ S'o/p (II) by the Substitution Lemma. By (d), 
this is the same as f] £ Sol© (11). 

Next, we note that rj £ Solx>(a) is equivalent to cry = r], which can be proved by 
the following chain of equalities: an —(d) aaa\r\ —( a ) oo\t\ =(d) V- D 

Lemma 8 {Auxiliary Completeness Lemma) 

Assume LI C PConx>, a 7 a\ £ Sub-p and 77,77' £ Val-p such that 77 £ SoZp (II) n 
Solj){a), G\rj — rj' and 77' =ypr 77, where Y' are fresh variables away from var{H) U 
vdom{a) U vran{a). Then arj — rj and 77' £ Solp{Hai) D Solx>{aai). 

Proof of Lemma [3 

In what follows we can assume an = -q due to the hypothesis 77 £ Solt>{a). 

We prove 1777' = 77' by showing that Xarj = Xrj holds for any variable X £ \hr. 
This is trivial for X ^ vdom{a). For A £ vdom{a), we can assume that Y 7 is away 
from X and i>ar(Aer); therefore 77' —x,var(Xa) V and hence Xarj = Xarj = Xr\ — 
Xrj (where the assumption ar\ — r] has been used at the 2nd step). 

Now we prove 77' £ Sol-p (Ilcri ) . Because of the Substitution Lemma [3J this is 
equivalent to a\ij £ Solr>{H), which amounts to 77 £ Sol-p {H) due to the hypothesis 
ayrj = rj', rj =\vi 77 and Y' away from var{H). But 77 £ Sol-p{H) is also ensured by 
the hypothesis. 

Finally, 77' £ Solp{aa\) is equivalent to aa\rj = 77', which can be proved as 
follows: aa\rj = arj = rj (where the 1st step relies on the assumption a\rj = rj 
and the 2nd step relies on a previously proved equality). □ 

Proof of Theorem [I] 

Consider the sts for 7i stores with transition relation tt~H, x as specified in Table 
[1] in Subsection 12.4.21 implicitly assuming that the notation used for the various 
strs is exactly the same as there. We prove that this sts satisfies the six properties 
enumerated in Definition [7] The last one (namely Local Completeness) holds for 
WZS-iree steps, where U1ZS = {OH3, OH7, H13} is the set of unsafe TC-strs, as 
explained in Subsection 12.4.21 
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1. Fresh Local Variables Property: The specification of the strs in Table Q] clearly 
guarantees this property. 

2. Safe Bindings Property: An inspection of Table Q] shows that the strs HI and 
H2 bind a variable to a constant, and the other strs never bind a variable X 6 X. 
Therefore, this property is also satisfied. 

3. Finitely Branching Property: This property holds because those strs that allow 
a non-deterministic choice of the next store provide only finitely many possibilities. 

4. Termination Property: Given a Ti. store II □ a and a set X C cvar(H), we define 
a 5-tuple of natural numbers ||U O £rj|^ —def {Pi, Pi, P3, Pa, P5) S N 5 where 

Pi is the number of occurrences of atomic constraints in II which are unsolved 
w.r.t. X. In this context, an atomic constraint 7r occurring in Id is said to be 
unsolved w.r.t. X iff some of the strs can be applied taking it as the selected 
atomic constraint. 

P2 is the sum of the depths of all the occurrences of variables X 6 X within 
patterns in Id. 

P3 is the sum of the syntactical sizes of all the patterns occurring in II. 

P4 is the number of unsolved occurrences of obviously demanded variables in IE. 
In this context, an occurrence of an obviously demanded variable X in II is 
called solved iff X occurs in a constraint of the form X == X, and unsolved 
otherwise. 

P5 is the number of occurrences of misplaced variables in EI. In this context, 

misplaced occurrences of X in II are those occurrences of the form t == X or 

t /= X, with t e Mir and X ^ t. 
Let >i ex be the lexicographic ordering induced by >n over N 5 . We claim that: 

(*) Hno-^ x Waa' => ||EIDa|U >ie X ||n' □ a'H* 

This is justified by Table [XT1 which shows the behaviour of the different strs w.r.t. 
>iex- In order to understand the table, note that two different cases have been 
distinguished for the application of the str Hn, namely: 

• Hixo Application of Hn choosing a value of i such that X n var(ti) ^ 0. 

• Hub Application of Hn choosing a value of i such that X n uar(fj) = 0. 

Since >i ex is a well-founded ordering, termination of Vt-h, x can be concluded from 
(*). The reader is referred to Section 2.3 in (Baader and Nipkow 1998) for more 
information on this proof technique. 

5. Local Soundness Property: Given a Ti. store II □ a and a set X C odvarn (II), 
we must prove that the union 

UiSolniBY 7 ^' □ a')) \ II □ a \h n , x W □ a', Y 7 = var(U' □ a') \ var{Ii □ a)} 

is a subset of Solx> (II □ a) . Obviously, it suffices to prove the inclusion 

(f) SolniBY 7 ^ □ cr')) Q Sol n {U □ a) 

for each EE □ a' such that II □ a H- H ,#! EI' □ a' with Y 7 = var(Tl' □ o-')\rar(EI □ a). 
However (f ) is an easy consequence of 

(tt) Sol n {W □ a') C Sol H (tt □ a) 
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Table A 1. Well-founded progress ordering for >i ex 

In fact, assuming (ft) and an arbitrary 77 6 SoI-h(3Y'(H' □ a')), there must be some 
if G Sol H {U' Ua') such that 77 =, F 7/ '. Then, 77' E Sol n (I\Ua) because of (ft), 
and thus i] G Soln(R □ cr) because 77 =\xn rf and Y' fl war(II □ cr) = 0. 
Having proved that (ff) entails (f), we proceed to prove (ft) by a case distinction 
according to the str used in the step II □ a Vrn, x II' □ cr'. In each case, we assume 
that the stores IT □ a and EE' □ cr' occurring in (ft) have exactly the form displayed 
for the corresponding transformation in the Table Q] displayed in Subsection 12.4.21 
For instance, in the case of transformation HI we write (t == s) — ►! R, II □ cr in 
place of II □ cr. Moreover, in all the cases we silently use the fact that the constraints 
and variables within any store are not affected by the substitution kept in that store. 

HI Assume r/ G Sol H ((t == s, II)(7i □ <ja{). Then 77 G Sol n ((t == s, II)cti) n 
Soln(o~o-i). We must prove 77 G Sol n ((t == s) — AR, HD a). 
Since (t == s,H) = (t == s, IT)cr, we can infer 77 G Solu{t == s, II) n Solji{a) 
from our assumptions and Lemma [7l 

It remains to prove that 77 G Soln((t == s) — >! R). Since we already know that 
77 G Sol-n(t == s), it suffices to prove that -R77 = true. But 77 G SoI-h(<j<ji) 
means uu\ 77 = 77, and therefore -R77 = Roo\r\ = R<j\r\ = true 77 = true. 
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H2 Very similar to HI. 

H3 Trivial. Clearly, Sol-}i{t m ——s rn ) = Sol?{(ht m == h~s~^). 
H4 Trivial. Clearly, Sol H (X == t) = Sol n {t == X). 

H5 Assume 77 6 S ' ol-j-i{tot{t) , YiaiUaai). Then trj is a total pattern and r\ G 
SoIh(Ro-i) n Sol n {o-oi). We must prove 77 s Sol n {X == t, II Da). 
Since II = Ha, we can infer r\ £ Solu{U)nSol-H(o') from our assumptions and 
Lemma [7] It remains to prove that 77 G Solyi(X == t). But rj G Sol-H{aa\) 
means aa\r\ = rj. Thus, Xr/ = Xaa\r\ = Xa\r\ = t-q, which implies 77 G 
Solu{X == t), because trj is total. 

H6 Trivial, because 77 G 5oZ^(B) is false for any 77. 

H7 Trivial. Clearly, Sol H (U / =s,) C Soln{ht^ /= h~s~^). 

H8 Trivial, because 77 G Soln(ht n 1= Zi's^T) holds for any 77. 

H9 Trivial, for the same reason as H6. 
H10 Trivial. Clearly, Sol n {X /= t) = Sol n {t /= X). 

Hll Assume 77 G Sol n ({Z l /= U, II)cti Daax). Then 77 G Sol H ((Zi /= U)ax) and 
77 G Solu(Rcri) ("1 Soln(o'ai). We must prove rj G Soln{X /= ct n , ilDcr). 
Since II = Ilcr, we can infer 77 G S'o^(n) n Soln(a) from our assumptions 
and Lemma [7] It remains to prove that 77 G Solu{X /= ct n ). Because of 
?7 G Sol-H(aai), we know that aa\r) — 77. Therefore, it suffices to prove 
aa\r\ G Sol-j-c(X /= ct n ), which can be reasoned as follows: 



aa\T\ G Soln{X /= ct n ) 77 G Sol n {X /= ct n )aai 
^> 77 G Sol H (X /= ct n )a 1 <=(2) 77 G Sol n (Zi /= hat) 
■<=(3) 77 G Sol n {Zi /= U)ai 



where (1) holds because of the Substitution Lemma [3l (2) and (3) hold by 
construction of a\, and 77 G Sol-j-c(Zi I- ti)o\ holds because of the assumptions 
of this case. 

H12 Assume 77 G Soln^criUaai). Then 77 G S'o^(no'i) n Soln {aai ) . We must 
prove 77 G Soln{X /= ct n , H □ a). 

Since n = Ilcr, we can infer 77 G S*o^(n) n Sol-u(a) from our assumptions 
and Lemma [Jj It remains to prove that 77 G Soln(X /= ct n ). This is the 
case because A77 = Xaain — Xa^ — (dZ m )rj, where the first equality holds 
because of the assumption 77 G Soluiaci) and the third equality holds by 
construction of a\. 
H13 Trivial, for the same reason as H6. 

6. Local Completeness Property for UTZS-iree steps: Recall the set of unsafe srjrs 
WIS = {OH3,OH7,H13} defined in Subsection [2X1 Assume a H store II □ a 
and a set X G odvar-j-c (II), such that II □ a is U1ZS- irreducible but not in <Y-solved 
form. We must prove that WTSoI-d(\1 □ a) is a subset of the union 

[j{WTSol v (3Y 7 (U'aa r )) \ Una W- n ,x n'Dcr',1 77 = var(U'aa') \ var(Uaa)} 

Given any well- typed solution 77 G WT S oI-h(H O a) (which satisfies in particular 
ar l — v) > we must find II' □ a' and 77' such that 

(t) n □ a Yrn.x n' □ a\ 7/ G WTSol H (n' □ a'), 77 = vF7 77' 
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so that 77 G WTSoIh(3Y'(H' □ a')) will be ensured. Because of the assumptions on 
II □ a, there must be some str H; ^ UTZS that can be used to transform II □ a. 
Below we analyze all the possibilities for H^, considering all the sirs shown in Table 
[T]in Subsection 12 . 4.21 except OH3, OH7 and H13. In all the cases we conclude that 
the conditions (\) displayed above can be ensured. When considering different strs 
that can be alternatively applied to one and the same store (as e.g. HI and H2) we 
group all the possibilities within the same case, arguing that some rule in the group 
can be chosen to transform IT □ a ensuring (I). In all the cases, we assume that the 
stores II □ a and II' □ a' occurring in (J) have exactly the form displayed for the 
corresponding transformation in Table [TJ we note the selected atomic constraint as 
tt, and we silently use the fact that the constraints and variables within any store 
are not affected by the substitution kept in that store. 

HI, H2 In this case tt is (t == s) -►! R, 77 G WTSol H (t == s ->l R, II □ a) and F 7 = 0. 
Because of n G WTSoI-h(tt), one of the two following subcases must hold: 

(a) rj(R) — true and 77 G WTSolu{t == s) or else 

(b) r)(R) = false and 77 G WTSol n {t /= s) 

Assume that subcase (a) holds. Then, (£) can be ensured by transforming 
the given store with HI and proving 77' = 77 G WTSoI-h(H(Ti Daai). Note 
that Lemma [8] can be applied with Y' = 0, rf = 77 and a\ = {R 1— > true}, 
because the condition eri?7 = r/ follows trivially from 7/(i?) = true. Then, 
r\ G Sol-j-i (n<Ti) n Sol-n(crai) is ensured by Lemma and 7/ obviously remains 
a well-typed solution. 

Assume now that subcase (b) holds. Then a similar argument can be used, 
but choosing H2 instead of HI. 
H3 In this case tt is ht m == hs~ m and (|) can be ensured by choosing to transform 
the given store with H3 and taking Y' — and a' — a. Note that h must be m- 
transparent because of the lAIZS-fceeness assumption, and the Transparency 
Lemma [2] can be applied to ensure that r\ remains a well- typed solution of the 
new store. 

H4 In this case tx is t == X, where t is not a variable, and (|) can be trivially 
ensured by choosing to transform the given store with H4 and taking Y' = 
and a 1 = a. 

H5 In this case tt is t == X, with X ^ X,X £ var(t),X ^ t. Moreover, 77 G 
WTSoIh{X ==t, n □ a) and Y 1 — 0. Then (f ) can be ensured by transforming 
the given store with H5 and proving 77' = 77 6 WTSol n {tot{t), Hai Oaa\). 
The assumption 77 G WTSoI-h(tt) means that n(X) — tr\ is a total pattern, 
so that 77(F) is also a total pattern for each variable Y G var(t). In these 
conditions, 77 G Soln(tot(t)) and 17177 = 77 holds for o\ = {X t}. This 
allows to apply Lemma [8] with Y' = 0, 77' = 77 and o~\, ensuring that 77 G 
Solfi{J\ai) n Solq-i{a<Jx). Obviously, 77 remains a well- typed solution. 

H7 In this case, tt is ht m /= hs m - Because of 77 G WTSolni^), there must be 
some index i such that 1 < i < m and 77 G WTSoln{ti /= s,). Then (£) can be 
ensured by choosing to transform the given store with H7 and this particular 
value of i, and taking Y' = = a. Note that h must be 77i-transparent 
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because of the WZS-heeness assumption, and the Transparency Lemma[2]can 
be applied to ensure that 77 remains a well-typed solution of the new store. 
H8 In this case 7r is ht n /= h's m with ft ^ ft' or n ^ m, and (£) can be trivially 
ensured by choosing to transform the given store with H8, taking Y' = and 
a' = a. 

H10 This is a trivial case, similar to H4. 
Hll, H12 In this case tt is X /= ct n , with X £ X, c £ DC n and X n var(ct n ) ^ 0, 
77 £ VFTSW W (X /= ct„nncr). Because of 77 G WTSofo (71-), one of the two 
following subcases must hold for rj(X): 

(a) rj(X) = cs n , where Sj/= TV? holds for some 1 < i < n. 

(b) rj{X) = ds m , where d £ DC m belongs to the same datatype as c, but 
d^c. 

Assume that subcase (a) holds. Then (J) can be ensured by choosing to trans- 
form the given store with Hll and a particular value of i such that s,/= tirj 
holds, taking Y' = Z n , defining 7/ as the valuation that satisfies rj'(Zj) = Sj 
for all 1 < j < n and T)'(Y) = r)(Y) for any other variable Y and proving 
i £ WTSol H {(Z l /= u, n)oi □ (rax). 

Obviously rj =\yv 77'. Moreover, airj' — 77', since Xa\rf = (c~s n )r)' = cs n — 
Xn = X-q' and Yairj' = Yrf for any variable Y ^ X. Therefore, Lemma 
[8] can be applied to ensure that 77' £ Solu(J^o-\) n Soln{o~o-i). Since 77 was a 
well-typed solution and data constructors have the transparency property (see 
Subsection 12. ip . rj' can be also well-typed under appropriated type assump- 
tions for the new variables Y' = Z n introduced by the transformation step. It 
only remains to prove that 77' £ Sol-n{{Zi/=ti)a{). This can be reasoned by a 
chain of equivalences, ending with the condition known to hold in subcase (a): 

77' £ Sol H ((Zi/=ti)ai) <^ (1 ) 0-177' £ Sol H (Zi/=t t ) <^> (2) 
77' £ Sol H (Zi/=U) ^ rf{Zi)Mirf 4^ (3) s l l=t l r( 

Note that (1) holds because of LemmaO (2) holds because u\rj = 77', and (3) 
holds by construction of 77'. This finishes the proof for this subcase. 
Finally, assume now that subcase (b) holds. Then (|) can be ensured by choos- 
ing to transform the given store with H12 and the particular data constructor 
d £ DC m for which we know that r](X) = ds m , taking Y' — Z m , defining 77' 
as the valuation that satisfies rf{Zj) = Sj for all 1 < j < m and rf(Y) = 77(F) 
for any other variable Y and proving 77' £ WTSoI-h (ILti □ erci). 
Obviously, 77 77'. Moreover, <j\v[ = 77' can be easily checked, as in subcase 

(a). Therefore, Lemma [5] can be applied to ensure that 77' £ Soln{X\.cr\) n 
Soljiiuux). Finally, since 77 was a well- typed solution, 77' is clearly also well- 
typed under appropriated type assumptions for the new variables Y' = Z n 
introduced by the transformation step. 

Using items 1. to 6. above and Lemma [5j we can now claim that solve^ satisfies 
the requirements for solvers enumerated in Definition [6J except that the Com- 
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pleteness Property is guaranteed to hold only for safe (i.e., UlZS-iree) solver 
invocations and the Discrimination Property has not been proved yet. 

The remark in item 1. of the proof of Lemma [5] allows to rephrase the Dis- 
crimination Property as follows: if a given Ti store II □ a satisfies neither (a) X (~l 
odvar(H) ^ nor (b) X n var(U) = then II □ a can be reduced by some 
M~n,x transformation. Assume that ITDer satisfies neither (a) nor (b). Because 
of -i (6), there must be some tt G H such that (c) X n var^ir) ^ 0. Because of 
-i (a), this tt must satisfy (d) X n odvar(ir) = 0, which together with (c) entails 
(e) X n cvar(n) =/= 0. Using (d), (e) and reasoning by case distinction on the syn- 
tactic form of tt, we find in all the cases some tt~n,x transformation which can be 
used to transform the store n □ a taking tt as the selected atomic constraint. The 
cases are as follows: 

tt is (t == s) —y\ R. In this case the store can be transformed by means of HI or 
H2. 

tt is ht m == hs m . In this case the store can be transformed by means of H3. 
tt is t == X with t ^ Vir. In this case the store can be transformed by means of H4. 
it is X == t with X £ var(t), X/i. Because of (d) above we know that X ^ X, 
and the store can be transformed by means of H5. 

tt is X == t with X € var(t), X ^ t. In this case the store can be transformed by 
means of H6. 

tt is ht m /= h~s m . In this case the store can be transformed by means of H7. 

tt is ht n /= h's m with h ^ h! or n ^ m. In this case the store can be transformed 

by means of H8. 

tt is t /= t with t G VirUDCUDFUSPF. In this case the store can be transformed 
by means of H9. 

tt is t /= X with t £ Vir. In this case the store can be transformed by means of 
H10. 

tt is X /= ct n , with c G DC n . Because of (d), (e) above we know that X ^ X and 
X n var(ct n ) 7^ 0. Therefore, the store can be transformed by means of Hll or 
H12. 

tt is X 1= ht m with h DC m . Because of (of), (e) above we know that X £ X and 
X n var(ht m ) ^ 0. Therefore, the store can be transformed by means of H13. 

This completes the proof of the Discrimination Property and the Theorem. □ 

We refrain to include in this Appendix a proof of Theorem[3l stated in Subsection 
12.61 and ensuring the properties required for the solver solve M . The proof would 
follow exactly the same pattern as the previous one, but with much simpler ar- 
guments, since the sts for .M-stores involves no decompositions. Actually, this sts 
is finitely branching, terminating, locally sound and locally complete. Therefore, 
Lemma [5] can be applied to ensure all the properties required for solvers, including 
unrestricted completeness. 

We end this subsection with the proof of Theorem [21 ensuring that the amal- 
gamated sums presented in Subsection 12.51 are well defined domains behaving as a 
conservative extension of their components. 
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Proof of Theorem [H 

Assume S = T>\ © • • • Q T) n of signature E constructed as the amalgamated sum of n 
pairwise joinable domains T>i of signatures Ej, 1 < i < n. Note that the information 
ordering C introduced in Subsection 12.21 has the same syntactic definition for any 
specific domain signature. Note also that any arguments concerning well typing 
needed for this proof can refer to the principal type declarations within signature 
E, which includes those within signature E^ for all 1 < i < n. Let us now prove the 
four claims of the theorem in order. 

1. S is well-defined as a constraint domain; i.e., the interpretations of primitive func- 
tion symbols p G SPF in S satisfy the four conditions listed in Definition Q] from 
Subsection 12.31 We consider them one by one, assuming that p is not the primitive 
== except in the fourth condition. 

(a) Polarity: Assume p G SPF m and t m ,t' m ,t,t' G Us such that p s t m — > t, 
t<m != t'm and t □ t' . In case that t is _L, we trivially conclude p t' n — > 
t' because t 1 must be also _L Otherwise, by the first assumption and the 
definition of p s , there must be some 1 < i < n and some t" m ,t" G Urji 
such that t" m Q t m , t" 3 t and p Di t" m — > t" . Since t" m C t m C i' m and 

F ' ¥ m -» t" implies p 5 ! 7 ™ -> by definition of p 5 . 

(b) Radicality: Assume p G SPF m and i m ,i G Z-/s such that p 5 i m — > * and 
t is not L. By the definition of p there must be some 1 < i < n and 
some F m , t" G Uv, such that ¥ m C < m , t" □ t and p v >W m -> t" . By 
the radicality condition for 2?^, there must be some total i' G such that 
P V ' t"m -> *' 3 Note that □ t" □ i, and because of F m C Z m and t' □ 
P' D< i"m — > i' implies p s t m — > i' by definition of p 5 . 

(c) Well-typedness: Assume p G SPF m , a monomorphic instance r' m — > r' of 
p's principal type and t m , t G Z/(s such that E I~wt ?m :: T 'm and t m — > t. In 
case that < is _L, the type judgement E ("vkt -L :: t' holds trivially. Otherwise, 
by the assumption p s t m — ► t and the definition of there exist 1 < i < n 
and t' m ,t' G such that t' m C i TO , t' □ t and p Vi t' m — > t'. Moreover, 
since £' m C J m the assumption E I~vkt - t'ot and the Type Preservation 
Lemma Q] imply E I~vkt t' m T' m Then, the well-typedness assumption for 
T>i guarantees E \~wt f :: t', which implies E \~wt t :: t' because of t C t' 
and Lemma [TJ 

(d) Strict Equality: The primitive == (in case that it belongs to SPF) is in- 
terpreted as strict equality over Us ■ This is automatically guaranteed by the 
amalgamated sum construction. 

2. Given an index 1 < i < n, a primitive function symbol p G SPF™' and values 
t m ,t G Ux>i, we must prove: p Di t m — > i iff p s I m — > i. By definition of p s , we know 
that p s t m — ► t holds iff there are some t' m , t' G such that t' m C I m , t' 3 i and 
P 1 ^ 1 1' m — > i'. But this condition is equivalent to p Di t m — » i because p 11 * satisfies 
the polarity property. 

3. Given an index 1 < i < n, a set of primitive constraints II C APCcm,D i and a val- 
uation 77 G Val-Di, we will prove: 77 G SoZ-d^II) <^> 77 G 5oZ5(II). The corresponding 
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equivalence for the case of well-typed solutions follows then easily. Since 

rj E Sofat (II) & Vtt e IT : 77 e Sol Vt (tt) & Vtt e n : rj E SoI s (tt) ^ 77 e Sol s (U) 

it suffices to prove the equivalence 

(*) r\ S Sol Vi (ir) <^> rj E SoI s (tt) 

for a fixed tt E IT. Note that tt must have the form pt m — ►! £ for some p E SPF™, 
t m E Patj) i and total £ E Pa£p i . In case that p is ==, (*) is trivially true because 
tiV == ' Di t2V ~ > '^ 7 7 an( i tiV~~ t2V ^-tf] hold under the same conditions, as specified 
in Definition [T] from Subsection 12.31 In case that p is not ==, let t' m = t m r) and 
£' = £77. If £' is not a total pattern, then neither 77 E SoI-d^) nor 77 E SoIs{tt) hold. 
Otherwise, 

?? E SoI Vi (tt) &p Vi ¥ m -> £' ^ ( ^) p 5 F TO -> £' 77 E SoI s (tt) 

where the (★*) step holds by the second item of this theorem, because t' m , £' E . 
4. Given an index 1 < i < n, a set of 2?i-specific primitive constraints II C APCon-D i 
and a valuation 77 E VaZ,s, we will prove: 77 E Sols(Tl) | 77 j^E SoZp^lT). The 
corresponding equivalence for the case of well-typed solutions follows then easily. 
First we prove 7/ E Sols(Jf) <= | 77 ^E SoZp^II). Assume | 77 Ix^E 5oZ Ci (II). 
Applying the previous item of this theorem, we obtain | 77 i^E So^s (II). Since 
I V Id.E we can apply the Monotonicity Lemma 3] and get 77 E SW,s(n), as 
desired. 

Now we prove 77 E Sols (II) =>■ | 77 5oZd 4 (II). Assume 77 E 5o's(II). Since 
IT is ZVspecific, we can also assume that 77(A) E U-D i for all A E var(n). Then 
77(A) = I 77 \x> i (X) holds for all A E var(U), and therefore | 77 |x> ; E Sols(U), which 
implies | 7/ |u ( G So/j^ (II), again because of the previous item of this theorem. 

□ 

A. 2 Properties of the CCLNC(V) Calculus 

The second part of the Appendix includes the proofs of the main results stated in 
Subection 13.61 First we present an auxiliary result which is not stated in the main 
text of the article. The (WT)Sol notation is intended to indicate that the lemma 
holds both for plain solutions and for well-typed solutions. 

Lemma 9 {Auxiliary Result for Checking Goal Solutions) 

Let G = 3U. P □ C □ M □ H □ F □ R be an admissible goal for a given 
C-FLP(C)-program V . Assume new variables Y' away from U and the other vari- 
ables in G, and two valuations /i, p E Vale such that p =\7jy t t 1 an d P 6 
(WT)Sol-p(P OCDMOHDFO R). Then fx E (WT)Sol v {G). 
Proof 

Consider p E Vale univocally defined by the two conditions p =ypr p and p =— /i. 
By hypothesis, p E (PFT)5o/ P (P OCUMUHOFUR) and the variables Y 7 do 
not occur in G. Therefore, p E (WT)Sol v (P OCUMOHUFOR) is ensured by 
the construction of p. Recalling Definition ITD1 (see Subsection 13. 6p . we only need to 
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prove ft =\f? M m order to conclude \i € (WT)Sol-p(G). In fact, given any variable 
X £ U, either X € Y' or X £ Y'. In the first case, fi(X) = fi(X) by construction 
of jX. In the second case, fi{X) = fi(X) by construction of fi and fi(X) = n(X) 
because of one of the hypothesis. □ 

Next we present the proof of Theorem Q] which guarantees local soundness and 
completeness for the one-step transformation of a given goal. 

Proof of Theorem [^] 

Assume a given program V, an admissible goal G for V which is not in solved form, 
and a rule RL applicable to a selected part 7 of G. The claim that there are finitely 
many possible transformations G H-rl^.p G'j (1 < j < k) can be trivially checked 
by inspecting all the rules in Tables [3J QJ [7] and [5] one by one. We must prove two 
additional claims: 

1. Local Soundness: Sol v (G) D U*=i Solvity). 

2. Limited Local Completeness: WTSol v {G) C \J k j=1 WTSol v {G' j ), provided 
that the application of RL to the selected part 7 of G is safe, i.e. it is neither 
an opaque application of DC nor an application of a rule from Table [5] involving 
an incomplete solver invocation. 

Claims 1. and 2. must be proved for each RL separately. In case that RL is some of 
the rules displayed in Table [3j proving 1. and 2. involves building suitable witnesses 
as multisets of CRWL(C) proof trees, using techniques originally stemming from 
([Gonz alez- Mor eno et al. 199 6: Gonzalez-Mor eno et al. 1999[) and later extended to 
CFLP programs without domain cooperation in ( |L6pez-Fraguas et al. 2004| . In 
case that RL is some of the rules shown in Tables |4j [7] and proving 1. and 2. 
requires almost no work with building witnesses. 

We will consider rules DF and FC as representatives for Table[3j and most of the 
rules from Tables (H [7] and [H which are the main novelty in this paper. When dealing 
with each rule RL, we will assume that G resp. G'j are exactly as the original resp. 
transformed goal as displayed in the presentation of RL in Subsection l3 . 2\ l3T3l or l3 .41 
In our reasonings we will use the notation M. : V ^crwl(c) {P^ C)fi' to indicate 
that the witness is a multiset of CRWL(C) proof trees that prove (POC)fj,' 
from program V, using the inference rules of the CRWL(C) logic presented in 
( |L6pez-Fraguas et al. 20070 . 

A. 2.1 Selected rules from Tabled 

Rule DF, Defined Function. In this case, 7 is a production fe n — > t. 

1. Local Soundness: Assume /i £ Sol-p(G'j) for some 1 < j < k. Then there exists 
H' =\yjj M suc li that // e Sol v (e n -> t n , r -> t, P □ C", CD M □ H □ F □ R). 
From this we deduce that fi' G Sol c (M □ H □ F □ R) and M' : V ^cbwl(C) 
(e„ — ► t n , r — * t, PO C', C)/i' for a suitable witness M! . A part of M! proves 
(e n — ► t n , r — > t, C')fi', which allows to deduce {fe n — > t)/u' using the CRWL(C) 
inference rule which deals with defined functions. Therefore, Ai' can be used to 
build another witness M : V ^crwl(C) (f^n ~> *j PaC)fx'. Since fi' =\jj fi, we 
can conclude that fi S Sol-p(G). 
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2. Limited Local Completeness: Assume p £ WTSol-p(G). Then there is some 
p! =sj? p such that p' £ WTSol v (fe n — ► t, PUCUMUHUFU R). Then, p! £ 
WTSol e (M UHUFUR) and M : P \- C RWL(C) (/ e„ ->■ t, P □ C>' for a suitable 
witness A4. Note that M. must include a CRWL(C) proof tree T proving the 
production (/e„ — > t)/j' using some instance of i?2 : f t„ — > r <== C", suitably 
chosen as a variant of some P rule with new variables Y — var(Rl). Let us choose 
j so that G'j is the result of applying DF with fe n — > i as the selected part of 
G and Rl as the selected P rule for /. Consider a well typed p" £ Vale that 
instantiates the variables in Y as required by the proof tree T, and instantiates any 
other variable V to p'(V). By suitably reusing parts of A4, it is possible to build 
a witness M' : P l~ciWL(C) (e n — ► t n , r — ► t, PD C", C)/i". Since //' =,y p /x, we 
can conclude that p € WTSol-p^G'j). 

Rule FC, Flatten Constraint. In this case, 7 is an atomic constraint pe n —>lt 
such that some is not a pattern and fc = 1 . We write G' instead of G[ . For the sake 
of simplicity, we consider pe\ t 2 — >! t, where e\ is not a pattern. The presentation 
of the rule is then as in Table [3] with n = 2, m = 1. 

1. Local Soundness: Assume p £ Sol-p(G'). Then there exists p! =\y 1 jj p such 
that G Sol v (ei ->V x ,PUpV x t 2 ->! i, C □ M □ P □ F □ P). Then, we get // 6 
SoZ c (Af UHUFUR) and A4' : P ^crwl{C) (ei -» Vi.PDpViia -»-!t, C)// 
for a suitable witness A part of proves (ei — » Vi, pVit 2 —►!<)//, which 
allows to deduce (peii 2 using the CRWL(C) inference rule which deals 
with primitive functions. Therefore, M! can be used to build another witness M. : 
V \~crwl(c) (P n P e i^2 — ►!£, C)//. Since // /i, we can conclude that p £ 
Sol v (G). 

2. Limited Local Completeness: Assume p £ WTSol-p(G). Then there is some 
p' =^ v p such that p' £ WTSol v (PUpe x t 2 -►!*, C □ M □ P □ F □ P). Then, 
//' G VyTS'o/c ( Af □ P □ F □ P) and A( : P h CWi(c) (PU pei t 2 -►!*, C)p' for a 
suitable witness A4. Note that M. must include a CRWL(C) proof tree T proving 
the atomic constraint (j> ei t 2 — >! t)p' . A part of T must prove a production of the 
form ei/i' — > ti for some suitable pattern ti. Consider a well typed p" £ Vale 
such that p"(V\) = fi and p" =\vi /•*'■ By suitably reusing parts of it is 
possible to build a witness M' : P l~ciW£(C) ( e i ~~ * V%, PUpVit 2 —*lt, C)p" . 
Since p" =\ Vl jj li, we can conclude that p £ WTSol-p(G'). 

A. 2.2 Rules from Table\Q 

Rule SB, Set Bridges. In this case, 7 is a primitive atomic constraint w which can 
be used to compute bridges, and k = 1. We write G' instead of G[. The application 
of the rule computes 3V B' = bridges D ^ v (it,Bm) 7^ 0, where V = TV and 
T>' = TZ or vice versa, according to the two cases (i) and (ii) explained in Tabled] 

1. Local Soundness: Assume p £ Sol-p(G'). Then there exists p! =\y7jj p such that 
p! £ Sol v {P □ 7T, CUM' UHUFUR). Therefore, p' £ Sol c {M' UHUFUR) and 
M' : P \~crwl(c) (P n ?r, C)p' for a suitable witness M' . Since M' is B',M, we 
get fx' £ Sol e (M UHUFUR) and M! : V \- C rwl(c) (P d tt, C>', which implies 
/i G Sol-p(G) because of Lemma [9] 



On the Cooperation of the Constraint Domains TL, 1Z and TT> in CFLP 103 



2. Limited Local Completeness: Assume p G WTSol-p(G). Then there is some 
p! p such that p! G WTSoI v {PUtt, CO MO HO FOR). Therefore, p! G 

WTSol c (M □ H □ F □ R) and M : V \~crwl(C) (P a t, C)p! for a suitable witness 
A4. Since tt is primitive, these conditions imply p! £ WTSoie(7r A Bm)- By item 2. 
of Proposition [T] from Subsection 13. 3i we know that V are new fresh variables and 
WTSol c (n A B M ) Q WTSoI c { : 3V 7 (tt A B M A B')). From this we can conclude that 
p! G W / TS , oZc(31 // (7r A Bm A B')) and therefore there is some p" =^ such that 
p!" G WTSoIc(ttABm AB'). Since V are new variables not occurring in G, it is easy 
to check that p" G W-TSW^M' □ i? □ F □ i?) and A4 : V *t C r.wl(c) (P d 7r, G)//', 
which ensures /x G T^TSo/^G')- 

Rule PP, Propagate Projections. In this case, 7 is a primitive atomic constraint 
tt which can be used to compute projections, and k = 1. We write G' instead 
of G[. The application of the rule obtains G' from G by computing 3V W = 
proj T '~* T ' (71", Bm) 7^= 0, where V = TV and V = 1Z or vice versa, according to the 
two cases (i) and (ii) explained in Tabled] The reasonings for local soundness and 
limited local completeness are quite similar to those used in the case of rule SB, 
except that item 3. of Proposition [1] must be used in place of item 2. 

Rule SC, Submit Constraints. In this case, 7 is a primitive atomic constraint tt 
and k = 1. We write G' instead of G\. 

1. Local Soundness: Assume p G Sol-p(G'). Then there exists p' =\jj P such that 
p! G Sol v {PUCUM'UH'UF'UR r ). Therefore, p! G Sol c (M' □ H' □ F' □ R') 
and M! : P ^cflWL(c) (-PDG)// for a suitable witness A4'. Due to the syntactic 
relationship between G and G' (see Table g|), // G Sol c {M' UH'UF'U R') amounts 
to p' G Sol c (M aHaFUR) and p! G Sol e {n). Due to // G 5oZ c (tt), the witness 
M! can be expanded to another witness M. : P t~crwl(C) {P aiT , C)p'. Thanks 
to this new witness we obtain p! G Sol-p(PUn, CnAlOHOFOR) and thus 
p G Sol v {G). 

2. Limited Local Completeness: Assume p G WTSol-p{G). Then there is some 
p! = VF such that p! G WTSol v (P □ tt, G □ M □ H □ F □ i?). Therefore, p' G 
WT5oZ c (M □ H □ F □ i?) and M : V \- C r,wl(c) [P n t> C)p! for a suitable witness 
A4. Because of the syntactic relationship between G and G' and the fact that tt 
is primitive, we can conclude that p! G WTSol c (M' UH'UF' U R'). Let M' be 
the witness constructed from M by omitting the CRWL(C) proof tree for 717/ 
which is part of M. Then M' : T 5 ^ciWL(c) {POC)p'. This allows to conclude 
p! G VFTSo/^P □ G □ M' UH'UF'U R') and thus /i G WTSol v (G'). 

A. 2.3 Rules from Table^ 

Rule IE, Infer Equalities. This rule includes two similar cases. Here we will treat 
only the first one, the second one being completely analogous. The selected part 7 
is a pair of bridges of the form X #== RX, X' #== RX and k = 1. We write G' 
instead of G[ . 
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1. Local Soundness: Assume p £ Sol-p(G'). Then there exists p! => jj p such that 
p! G Sol v {P □ C □ A #== AX, M □ i? □ X == X', F □ -R). This implies two facts: 
firstly, M' : V ^crwl{c) (P a C)p' for a suitable witness A4'; and secondly, p! £ 
Sol c (X #== RX, MUHUX == X', FUR). The second fact clearly implies p! £ 
Sol c (X #== FX, X' #== RX, MUHUFUR). Along with the witness M' , this 
condition guarantees pf £ Sol v (P □ C □ X #== FA, X' #== FA, M □ F" □ F □ F) 
and hence /i G Solp(G). 

2. Limited Local Completeness: Assume /i G W^TSWp(G). Then there is some 
p! M such that p! G WTSol v (P □ C □ X #== FX, X' #== FX, M OHO FOR). 
This implies two facts: firstly, A4 : P I~c.rwl(c) (-P 1=1 C)m' f° r a suitable witness 
A^; and secondly, /ti' G J¥TSoZ c (A #== FA, A' #== RX, MUHUFUR). The 
second fact clearly implies p! G WT5oZ c (X #== FX, M □ if □ X == A', F □ F). 
Then, /i' G WTSoZp(F □ C □ A #== FX, M □ F □ A == A', F □ F) holds thanks 
to the same witness M., and therefore p £ Sol-p(G'). 

Rule ID, Infer Disequalities. This rule includes two similar cases. Here we con- 
sider only the first one, the second one being completely analogous. The selected 
part 7 is an antibridge of the form A #/== v! placed within the M store, and 
k = 1. We write G' instead of G[. The application of the rule obtains G' from G 
by dropping A #/== u' from M and adding a semantically equivalent disequality 
constraint X /= u to the F store. The reasonings for local soundness and limited 
local completeness are very similar to those used in the case of rule IE. 

A. 24 Rules from Tabled 

Here we present only the proofs concerning the two rules FS and SF. Note that the 
soundness and completeness properties of the TT> solver refer to valuations over 
the universe UfT>, that must be related to valuations over the universe Uq by means 
of Theorem [2] from Subsection 12.51 as we will see below. The same technique can 
be applied to the rules MS and RS. Rule HS can be also handled similarly to FS, 
but in this case Theorem [5] is not needed because the soundness and completeness 
properties of the extensible F-solver refer directly to valuations over the universe 
U c . 

Rule FS FP-Constraint Solver {black-box). The selected part 7 is the F2?-store 
F. 

1. Local Soundness: Let us choose G 1 as one of the finitely many goals G'j such 
that G H- fs , 7 ,p G'j. Then G' = 3Y 7 , U.(P □ CuMuH □ (II' Ua F ) U R)@jr V( j' for 
some 3Y'(H' Oct') chosen as one of the alternatives computed by the FD-solver, 
i.e. such that n^? l^ so ; t , e ^x> 3V' (II' Der'). Assume now p G Sol-p(G'). Then there 
exists p! =\vTj] p such that 

p! G Sol v ((P U C U M U H U (n' □ (7 p) U R)@jr V a') 

for some 3F 7 (n' □ a') such that U F H- „ olve n> 3F 7 (n' □ a'). Since n' □ a' is a store, 
we can assume li'a 1 = H' and deduce the following conditions: 

(0) M' : V \~crwl{C) (P D C)a'p' for a suitable witness M' 
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(1) n' E Sol c {n M a' □ g m * a') (2) fi' E Sol c (U H o-' □ a H * a') 

(3)// 6 5oZ c (nVDfT F o-'), where nV = II' (4)// E Sofc (n^cr' □ * a') 
In particular, (3) implies \i' E SoI(o~fo~'), i.e. 

(5) aFO~'fJ,' = 

In order to conclude that /i 6 Sol-p(G), we show that the hypothesis of the aux- 
iliary Lemma [5] hold for /* = //. Clearly, jl =\7jy> A* an d the new variables 
Y' are away from U and the other variables in G. We still have to prove that 
p! E Sol v (P UCUMUHUFUR). 

• Proof of // E Sol-p (P □ C) : Due to the invariant properties of admissible 
goals, (P □ C) = (P □ C)<tf- Using this equality and (5) we get (P □ C)& V = 
(P □ C)a F a'fx' = (P □<?)//. Therefore, A4' : P h cwl(c) (P □ C)// follows 
from (0). 

• Proof of ll' E Solc(S), S being any of the stores M , H, R: According to the 
choice of S we can use (1), (2) or (4) to conclude 

(6)// E Sol c Ql s a') and (7) // E Sol(o~s * o~') i.e. (erg o~')fi' = /jf 

— Proof of fi' E Solc(Hs)'- Due to the invariant properties of admissible goals, 
lis = Hso-p. Then (6) is equivalent to fif E SoIc(TIso~fo~')- By applying 
the Substitution Lemma[3]we deduce crpcr' fi' E Solc(Tls), which amounts 
to y! E Sole (lis) because of (5). 

— Proof of \i' E Sol (as)'- Assume any variable A E vdom(as). Then 

Xfi' = Xo~so~' ' \J = Xo~ qg po~ ji = Xo~sti' 

where the first equality holds because of (7), the second equality holds 
because the admissibility properties of G guarantee o~s*o-p = erg, and the 
third equality holds because of (5). 

• Proof of n' E Solc(F): First, we claim that 

(8) I a'fi' \rve Sol(a') i.e. a' | a> y! \ rv = \ o '// \ TV 

To prove the claim, assume any X E vdom(a'). Because of Postulate [5] there 
are two possible cases: 

(a) cr'(X) is an integer value n. Then: 

AV I a'fi' \jr V = n = I AV// \fd= X \ & '// 

(b) X E tw(II F ) and cr'(X) is a variable A' E var(Tl F ). Then cr'(A') = A' 
because c' is idempotent, and: 

Xa' I |jtj= A' I a'// |^d= I XV// |^73= 

I A'/i' |;ft>= I ActV' |;ft>= A I a' [i \jr V 
We continue our reasoning using (8). 

— Proof of // E S , o^c(n F ): From (3) and the Substitution Lemma [3] we get 
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a' p! G SoZc(n'). Because of Postulate [2] we can assume that all the con- 
straints belonging to II' are .F2?-specific. Then, item 4. of Thcorcm[2]can be 
applied to conclude | a' p! |jr-pG Sol^ v (Jl'). Using (8) we get | a'p' \rx>& 
Soljr V {W Da'), which trivially implies | a'p' Soljr V {3Y 7 {n' a a')). 

Because of the soundness property of the JFD-solver (see Definition [6] and 
Postulate [2]) we obtain | a'p' |jt-dG So1^t>(J^f)- Applying again item 4. of 
Theorem[2] we get a'p' G SoIc(Hf)- Since IT? □ of is a store, 11^ = lip^F 
and therefore a' p' G SoIc(Hf&f)- Then, the Substitution Lemma [3] yields 
<jfo 'a*' G 5oZc (lip), which is the same as ^' G SoIc{Hf) because of (5). 
— Proof of p! G Sol(ap)- pi = app' follows from the following chain of 
equalities, which relies on (5) and the idempotcncy of of'- 

p! = opo~' p = a pa Fa' p! = o~fh' 

2. Limited Local Completeness: At this point we assume that rule FS can be 
applied to G in a safe way, i.e. that the solver invocation solve^ (Hf) satis- 
fies the completeness property for solvers stated in Definition [6] (see Subsection 
I2.4.1|) . Assume p G WTSol-p(G). Then there is some pi =wj p such that p! G 
WTSol v (P UCUMUHUFUR). Consequently, we can assume: 

(9) (P □ C)p' is well-typed and M : V ^crwl(C) (P d C)p' for some witness M 

(10) p! G WTSolc(M) (11) p G WTSolc(H) 

(12) p! G WTSolc(F) (13) pi G WTSolc(R) 

In particular, (12) implies p' G WTSol c (n F ). Thanks to Postulated we can assume 
that Hf is .FX>-specific and apply item 4 of Theorem [2] to conclude | p! |jr-pG 
WTSoIfd^f)- By completeness of the solver invocation solve^ (Uf) there is 
some alternative 3Y'(T1' Do-') computed by the solver (i.e. such that IIf Vr so i ve ^T> 
3Y T (U'na')) verifying 

(14) | p! \ rv £ WTSolrv (3F 7 (n' □ a')) 

Then G' = 3Y 7 , U.(P □ CUMUHU (IT □ a F ) □ R)@r V a' is one of the the finitely 
many goals G'j such that G M~Fs,-y,v G'j- In the rest of the proof we will show that 
p G WTSol-p(G') by finding p" =\y7 jj A 1 sucn that 

(f) p" G Sol v ((P □ CU M □ H □ (H' □ a F ) □ R)@rvo-') 

Because of (14) there is // G Ua^-p such that 

(15) | p! \rv=\- A G WT5rfjT?(n' □ a') 

Let //' G Vaic be univocally defined by the conditions p" — — p and p" =\vT f 1 ' ■ 
Since p —^jj p' , it follows that p" =\— jj Moreover, | p" \^v— Aj because 
for any variable X G Ihr there are two possible cases: either X € Y' and then 
I m" \fv (A) = | A \tt> (A) = p(X), since p G FaZ^-p; or else X £ Y' and 
then | p" \jr V (X) = | p! \rx> (A) = p(X), since | /i' |jT?=\-y7 A- From (15) and 
| p" \ FD = A wc obtain p" G WT5oZ^d(II') by applying item 4 of Theorem [2] Wc 
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now claim: 

(16) fi" G WTSoy v (W □ a') 

To justify this claim it is sufficient to prove fi" G Sol (a'), i.e. a'fi" = fi". In order 
to prove this let us assume any X G vdom(a'). Because of Postulate [21 there are 
two possible cases: 

(a) a'(X) is an integer value n. From (15) we know p, G Sol(a') and therefore 
fi(X) = n. Since | fi" \tt>= A> it follows that fi"(X) = n, and then Xa'fi" = 
n = Xfi". 

(b) X G var(U F ) and cr'(X) is a variable X' G var(U F ). Then: 

Xcr'/x" = X'fl" 

= X'fi' (using /it" = x7 t fi' and X' £ F 7 ) 

= | X'/i' (using the fact that 11^ is ^P-specific and (12)) 

= X' \n' \jn3 _ 
= X'p, (using (15) and X' £ Y') 

= Xa'fi = Xfi (using (15)) 

= X \n' \jr V (using (15) and X f Y 7 ) 

— | Xfi' \jr V — Xp! (using the fact that 11^ is ^P-specific and (12)) 
= Xn" (using n" = X yr n' and X £ Y>) 

We are now in a position to prove (f), thereby finishing the proof: 

• Proof of fj," G WTSol v (P □ C)a'\ Because of the Substitution LemmaGl this 
is equivalent to a'fi" £ WTSol v {P □ C). Because of (16), a'fi" = fi" . Since 
fi' = v — fi" and the variables Y 7 do not occur in P □ C, fi" G WTSol v {P □ C) 
is equivalent to // G WTSol-p(P □ C), which is ensured by the same witness 
tV4 given by (9). 

• Proof of fi" G WTSol c (S*o-'), S being any of the stores M, H, R: According 
to the choice of S we can use (10), (11) or (13) to conclude 

(17) fi' G WTSol c (Tl s ) and (18) fi' G Sol(a s ) i.e. a S fi' = fi' 

— Proof of fi" G WTSol c (U s o-'): Since fi" fi' and the variables Y 7 do 
not occur in n^, (17) implies fi" G WTSolc(Hs), which is equivalent to 
a'fi" G WTSolciUs) because of (16). Then, fi" G l^T5o? c (n S CT') follows 
from the Substitution Lemma [3J 

— Proof of fi!' G WTSol(as*a'): Assume any variable X G vdom{a s) ■ Then 

Xa s a'fi" = Xa S fi" = Xa S fi' = Xfi' = Xfi" 

where the first equality holds because of (16), the second equality holds 
because fi" =\y 7 I 1 ' an d the variables Y' do not occur in Xas, the third 
equality holds because of (18), and the fourth equality holds because 
fi" =vy7 fi' and the variables Y' do not include X. 

• Proof of ft" G WTSol c (U'a' □ o F o'): 

— Proof of fi" G WTSolc{H'a'): This is a trivial consequence of (16), since 
n'cr' = LT' (because n' □ a' is a store). 
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— Proof of p" G Sol{aFcr'): Because of (16) we can assume that //' € Sol(a'), 
i.e. a'p" = p" . We must prove ofo' p!' = p" . Assume any variable X G 
vdomiupa'). Because of the invariant properties of admissible goals, there 
are three possible cases: 

(a) X G vdom(aF) and <jf(X) is an integer value n. Because of (12), we 
know that p! G SoKcrp) and hence Xapp' — n — Xp' . Moreover, 
Xp" = Xp! = n because p" =yp7 m' an d the variables Y 1 do not 
include X. Then we can conclude that Xapa' ' p" = n = Xp". 

(b) X G vdom(a F ) and a F (X) = X' G var(Tl F ). Then: 

Xapcr'p" = X'a'p" 

= X'p" (using (16)) 

= X'p' (using p" = x7 r p! and X' Y 7 ) 

= Xa F p' = Xp' (using (12)) 

= Xp" (using p" = x — p! and X £ Y 7 ) 

(c) X ^ vdom{oF)- Then Xerp = X, and we can use p" G Sol(a') to 
deduce that Xa F a'p" = Xa'p" = Xp". 

Rule SF, Solving Failure. The selected part 7 is one of the four stores of the goal, 
the number k of possible transformations G H^rl^,-? G'j of G into a non-failed goal 
G'j is 0, and therefore U*=i WTSolviG'j) = 0. 

1. Local Soundness: The inclusion Sol-p(G) 3 holds trivially. 

2. Limited Local Completeness: The inclusion WTSol-p(G) C is equivalent to 
WTSol-p(G) — 0. In order to prove this, we assume that the application of SF 
to G has relied on a complete invocation of the T> solver. Since the invocation of 
the solver has failed (i.e., lis H~ solve' but it is assumed to be complete, we 
know that WTSolv (n s ) = 0. From this we can conclude WTSol c (Us) = 0, using 
item 4 of Theorem [2] in case that V is not H. Finally, WTSol v {G) = is a trivial 
consequence of WTSolc(Hs) = 0- 

□ 

A. 2. 5 Proof of the Progress Lemma 

In this Subsection we prove the Progress Lemma [6] used in Subsection 13.61 to ob- 
tain the Global Completeness Theorem [6] First, we define a well-founded progress 
ordering l> between pairs (G, M) formed by an admissible goal G without free 
occurrences of higher-order variables and a witness M. = {Ti, . . . ,T n } for the 
fact that p G Sol-p(G). Given such a pair, we define a 7-tuple ||(G,A^)|| =def 
(Oi, 02,0s, 04,0^,0^,07) (where Oi is a finite multiset of natural numbers and 
O2, ■ ■ ■ , O-j are natural numbers) as follows: 

Oi is the restricted size of the witness A4, defined as the multiset of natural 
numbers {| 7i |, . . . , | T n |}, where % \ (1 < i < n) denotes the restricted 
size of the CRWL(C) proof tree % as defined in ( |L6pez-Fraguas et al. 2007| , 
namely as the number of nodes in % corresponding to CRWL(C) inference 
steps that depend on the meaning of primitive functions p (as interpreted in 
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the coordination domain C) plus the number of nodes in % corresponding 
to CRWL(C) inference steps that depend on the meaning of user-defined 
functions / (according to the current program V). 

02 is the sum of ||pe„|| for all the total applications pe n of primitive functions 
p G PF n occurring in the parts P and G of G, where ||pe„|| is defined as the 
number of argument expressions ej (1 < i < n) that are not patterns. 

03 is the number of occurrences of rigid and passive expressions he n that are 
not patterns in the productions P of G. 

04 is the sum of the syntactic sizes of the right hand sides of all the productions 
occurring in P. 

05 is the sum sf M + sf H + sf F + sf R of the solvability flags of the four constraint 
stores occurring in G. The solvability flag sf M takes the value 1 if rule MS 
from Tabled] can be applied to G, and otherwise. The other three flags are 
defined analogously. 

C>6 is the number of bridges occurring in the mediatorial store M of G. 
O7 is the number of antibridges occurring in the mediatorial store M of G. 

Let >i ex be the lexicographic product of the 7 orderings >i (1 < i < 7), 
where >i is the multiset ordering > m ui over multisets of natural numbers, and 
>i is the ordinary ordering > over natural numbers for 2 < i < 7. Finally 
let us define the progress ordering t> by the condition (G,Ai) > (G',Ai') iff 
|(G,A4)|| >iex \\(G',M')\\. As proved in ( |Baader and Nipkow 1998[ ), > mu i is a 
well-founded ordering and the lexicographic product of well-founded orderings is 
again a well-founded ordering. Therefore, t> is well-founded. 

Now we can prove the Progress Lemma H3 

Proof of Lemma [6] 

Consider an admissible goal G = 3U. PUCUMUHUFURioY& pro- 
gram V, a well- typed solution \i <E WTSol v {G) and a witness M. for the fact that 
[i G Sol-p(G). Assume that neither V nor G have free occurrences of higher-order 
variables, and that G is not in solved form. 

1 . Let us prove that there must be some rule RL applicable to G which is not a failure 
rule. Since G is not in solved form, we know that either P ^ , or else C ^ 0, or 
else some of the transformations displayed in Tables [7] and [8] can be applied to G. 
Note that CF cannot be applied to G because G has got solutions. Moreover, if the 
failing rule SF would be applicable to G, then some of the other rules in Table [5] 
would be applicable also. Let P1Z be the set of those transformation rules displayed 
in Table[3]which are different of CF, EL and FC. In the following items we analyze 
different cases according to the from of G. In each case we either find some rule RL 
that can be applied to G or we make some assumption that can be used to reason 
in the subsequent cases. In the last item we conclude that rule EL can be applied, 
if no previous item has allowed to prove the applicability of another rule. 

(a) If some of the transformation rules in Tables [7] and [8] can be applied to G, 
then we are ready. In the following items we assume that this is not the case. 
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(b) If P 7^ and some rule RL e VIZ can be applied to G, then we are ready. In 
the following items we assume that this is not the case. 

(c) Due to the hypothesis that G has no free occurrences of higher-order variables, 
from this point on we can assume that each production occurring in P must 
have one of the three following forms: 

i he m — > X, with he m passive but not a pattern. 

ii fe n a k -> X, with / e DF n and k > 0. 

iii pe n — » X, with p e PF". 

If this were not the case, then P would include some production e — ► t of 
some other form, and a simple case analysis of the syntactic form of e — » t 
would lead to the conclusion that some rule RL 6 VIZ could be applied to it. 

(d) If C ^ and includes some atomic constraint a that is not primitive, then the 
rule FC from Table [3] can be applied to a, and we are ready. In the following 
items we assume that this is not the case. 

(e) If C ^ and only includes primitive atomic constraints 7T, then at least rule 
rule SC from Table H (and maybe also rules SB and PP) can be applied to 
G taking tt as the selected part, and we are ready. In the following items we 
assume that C = 0. 

(f) At this point, if there would be some variable X £ pvar(P) D odvar(G), this 
X would be the right-hand side of some production in P with one of the three 
forms i, or ii or iii displayed in item (c) above, and one of the three rules IM 
or DF or PC could be applied, which contradicts the assumptions made at 
item (b). From this point on, we can assume that pvar(P) O odvar(G) = 0. 

(g) Let S = Us □ as be any of the four stores, let V be the corresponding domain, 
and let x = pvar(P) n var(Tls). Because of the assumptions made at item 
(a), S must be in %-solved form and the discrimination property of the solver 
solve ensures that one of the two following conditions must hold: 

i x H odvar-p(Ils) ^ 0, i.e. pvar(P) n var(Us) H odvar-u{Y\s) i= 

ii x H varx>(Tls) = 0, i-C pvar(P) (1 var(Us) = 0. 

Since i contradicts the assumption pvar(P) n odvar(G) — made at item (f), 
ii must hold for the four stores. On the other hand, the invariant properties 
of admissible goals guarantee that produced variables cannot occur in the 
answer substitutions as- 

(h) At this point, because of the assumptions made at the previous items, we can 
assume that C = 0, the four stores are in solved form and include no produced 
variables, and all the productions occurring in P have the form e — > X , where 
X is a variable. Since G is not solved, it must be the case that P ^ 0. 
Note that pvar(P) is finite and not empty. Moreover, the transitive closure 
^>p of the production relation ^>p between produced variables must be ir- 
reflexive, due to the invariant properties of admissible goals. Therefore, there 
is some production (e — > X) G P such that X is minimal w.r.t. 3>p. 

The variable X cannot occur in e because this would imply X ^$>p X , con- 
tradicting the irreflexivity of 3>p. For any other production (e' — > X') e P, 
X must be different of X 1 because of the invariant properties of admissible 
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goals, and X cannot occur in e' because this would imply X ^>p X', con- 
tradicting the minimality of X w.r.t. 3>p. Moreover, X cannot occur in the 
stores because they include no produced variables. 

Therefore, X does not occur in the rest of the goal, and the rule EL can be 
applied to eliminate e — > X. 

2. Assume now any choice of a rule RL (not a failure rule) and a part 7 of G, such that 
RL can be applied to 7 in a safe manner, i.e. involving neither an opaque applica- 
tion of DC nor an incomplete solver invocation. We must prove the existence of a 
finite computation G H-^ L lV G' and a witness A4' : [i S WTSol-p(G') such that 
(G,M) > (G',M r ). Due to the Limited Local Completeness of CCLNC(C) (The- 
orem |U item 2.), there is one step G H~rl,7,p G[ such that M! : \i S WTSol-p(G') 
with a witness M! constructed as we have sketched in the proof of Theorem |H We 
define the desired finite computation by distinction of cases, as follows: 

(a) If RL is different from the two rules SB and PP, then the finite computation 
is chosen as G H-r,l, 7 ,-p G[ and G' is G[. 

(b) If RL is SB and PP is applicable to 7, then the finite computation is chosen 
as G H~~ sb,7 v G'i H~~ pp 7i 73 G'2 H~~ sc 7,7 s G(j and G is G3. 

(c) If RL is SB and PP is not applicable to 7, then the finite computation is 
chosen as G H~sb, 7 ,:p G'x H~sc, 7 ,:p G' 2 and G' is G 2 - 

(d) If RL is PP and SB is applicable to 7, then the finite computation is chosen 
as G ^"pp.'y.'p G'i ^sb.j.v G2 H~ sc, 7 , , p G3 and G' is G3. 

(e) If RL is PP and SB is not applicable to 7, then the finite computation is 
chosen as G H-pp, 7 ,-p G[ H-sc, 7 ,-p G' 2 and G' is G 2 . 

Note that cases (b), (c), (d), and (e) above refer to the rules in Tabled) In all 
these cases, the Limited Local Completeness of CCLNC(C) allows to find all the 
computation steps and a witness M.' : [i 6 WTSol-p(G'). In all the cases, we claim 
that (G,M) > (G',M f ), i.e. ||(G,M)|| >i ex \\(G',M')\\. This can be justified by 
Table IA 21 Each file of this table corresponds to a possibility for the rule RL used 
in a one-step finite computation G 7 v G' of type (a), except for one file which 
corresponds to a finite computation G H-^ L v G' of type (b), (c), (d) or (e). Each 
column 1 < i < 7 shows the variation in Oi according to >i when going from 
||(G,./Vf)|| to ||(G',.M')|| by means of the corresponding finite computation. For 
instance, the file for IE shows that the application of this rule does not increase Oi 
for 1 < i < 5 and decreases Oq. 

It only remains to show that the information displayed in Table [A~2l is correct. Here 
we limit ourselves to explain the key ideas. A more precise proof could be presented 
on the basis of a more detailed construction of the witnesses A4' : /1 £ WTSol-p(G'). 

• For every rule RL, the application of RL does not increase 0%, as shown by 
the first column of the table. This happens because the witness M can be 
constructed from M in such a way that all the inference steps within M' 
dealing with primitive and defined functions are borrowed from M.. 

• The application of any of the rule DF strictly decreases Ox, as seen in the 
table. The reason is that the witness M. includes a CRWL{C) proof tree T 
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RULES 


Oi 


o 2 


o 3 


04 


Or, 


o 6 


Or 


DC 


>m«I 
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> 








SP 


>m u ! 


> 
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> 








IM 


> mu ! 


> 


> 










EL 


>mul 


> 


> 


> 








DF 


>mul 














PC 


>,nul 


> 


> 


> 








FC 


>mu! 


> 












(b),(c),(d),(e) 


> mU ! 














IE 


>mu! 


> 


> 


> 


> 


> 




ID 


> m u! 


> 


> 


> 


> 


> 


> 


MS 


>mu! 


> 


> 


> 


> 






HS 


> mU ! 


> 


> 


> 


> 






FS 


> mU ! 


> 


> 


> 


> 






RS 


> m u! 


> 


> 


> 


> 







Table A 2. Well-founded progress ordering > for CCLNC{C) 

for an appropriate instance of a production of the form fe n -» i, The root 
inference of this proof tree contributes to the restricted size of M. and disap- 
pears in the witness M! constructed from Ai as sketched in Subsection lA.2.ll 
Therefore, the restricted size of M! decreases by one w.r.t. the restricted size 
of M. 

• The table also shows that finite computations of type (b), (c), (d) or (e) 
strictly decrease 0\ . The reason is that such finite computations always work 
with a fixed primitive atomic constraint 7r which is ultimately moved from the 
constraint pool C of G to one of the stores in G' when performing the last SC 
computation step. The witness M : \x € WTSol-p(G) includes a CRWL(C) 
proof tree for an appropriate instance of tt, while no corresponding proof tree 
is needed in the witness M! . Therefore, the restricted size of M! decreases by 
some positive amount. 

• The application of rule FC decrements O2, because G includes a production 
pen — * t with ||p en 1 1 > 0, which is replaced in G' by a primitive atomic 
constraint pt n — At with ||pt n || = and some new productions e t — > Vi 
whose contribution to the O2 measure of G' must be smaller than ||pe n ||. 
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The application of rule IE decreases Oq and does not increment Oi for 1 < 
i < 5. This is because in this case the witness M! can be chosen as M itself, 
the measures 02,03,04 and O5 are obviously not affected by IE, and the 
measure Oq obviously decreases by 1 when IE is applied. 
Because of similar reasons, the application of rule ID decreases O7 and does 
not increment Oi for 1 < i < 6. 

Let RL be any of the four constraint solving transformations MS, HS, FS 
and RS. The witness M! : n S WTSol-p(G') can be guaranteed to exist 
only if the solver invocation has been a complete one. In this case, M 1 can be 
chosen as the same witness Ai, and therefore the 0\ measure does not increase 
when going from G to G' . Measures O2, O3 and O4 are not affected by the 
bindings created by the solver invocations (since they substitute patterns for 
variables). Measure O5 obviously decreases, since the solvability flag sf s for 
the store that has been solved descends from 1 to 0. 



